5 replies to this topic

[Jahonno]

Hello

 

i used Indisk since years with out any problem. It worked suprep.

 

But now, on my new Win7/64 16GB machine...

Some time it worked too the, but since a few days:

 

I always run into BSOD since some days when trying to mount any iso,img,vdi (does not matter what i do and use using the GUI do not work either)

To my surprise: the BSOD says it is writing a dump, but there is no minidump or dump.

 

Got

early BSODs with

0x000000D3

And most often(always now

0x000000C1 “Special_Pool_Detected_Memory_Corruption”

 

I installed (and removed) MUTT (Microsoft USB Test Tool) and drivers for Renesas 2.x and 3.x USB3.0-Cards

(drivers are removed and cards are unplugged from PCIe slots)

Memory is reduced to 4GB, CPU ist still a Xeon with 4x2 kernels.

 

Installed 1.7.2, remove it, reinstalled 1.6: No change.

(Removed driver by manually renaming then as the uninstaller signals only an error....)

 

Event log is clear. Nothing except that it was shutdown unexpectetly...

 

 

Using WinCDemu to mount iso works, but i need to mount a floppy image...

 

I have no other problems with the box (Intel D3067-A1 mother board with Xeon)

 

 

Steps to reproduce:

 

To cause th BSOD immediately a

imdisk.exe -a -t vm -m X: -s 640M -p "/fs:ntfs /v:RamDisk /q/c/y"

is sufficient. (Found that line somewhere in the www)

 

 

To do it with delay:

 

DiscUtilsDevio gives after some time (approx. one or two minute)  a BSOD.

 

 

c:\>cd “c:\Program Files (x86)\ImDisk “

c:\Program Files (x86)\ImDisk>DiscUtilsDevio.exe /mount=q: /filename="O:\ISO\Arconis2013.iso"

Opening image O:\ISO\Arconis2013.iso

Image type class: DiscUtils.Optical.Disc

Unknown partition table format or partition table not found.

Image virtual size is 309592064 bytes

Image sector size is 2048 bytes

Partition table not found.

Using entire image file: O:\ISO\Arconis2013.iso

Used size is 309592064 bytes

Read/write mode.

 

[“hangs” until CNTL-C]

 

Other shell i can’t asccess the drive:

 

C:\Windows\System32>dir q:

Auf dem Datenträger befindet sich kein erkanntes Dateisystem.

Stellen Sie sicher, dass alle benötigten Dateisystemtreiber geladen sind und das

s der Datenträger nicht beschädigt ist.

 

After terminating the mount command with cnd-c the shell with

C:\Windows\System32>dir q:

hangs.

Edited by Jahonno, 15 May 2013 - 04:41 PM.

[Olof Lagerkvist]

This sounds like some compatibility issue with some other driver on that machine. But that is, of course, only a guess.

 

There should be a .dmp file generated in C:\Windows and as you describe there is none like that I would assume either that you have no pagefile on the system drive, or that it is too small, or that the crash affects the filesystem or disk drivers in such a way the dump could not be written to disk. In that case the only option, usually, is to attach a kernel debugger from another machine and run entire Windows system under that debugger until the crash shows up.

 

If you find something else that could make it actually write a dump file, it would be interesting to load that into WinDbg and see what actually happened.

 

Just a thought about your downgrade to 1.6.0. I understand that you just renamed imdisk.sys and replaced it with the version from an older install package? Did you remember to actually restart the driver, for example net stop imdisk and net start imdisk (or reboot)?

[Jahonno]

Hello

 

thanks for the fast reply. As i got no .dmp i tired to find the driver.

To get more Infos i attemted to

- let "verifier.exe" check all but MS-Driver and "low resource" condition.

A reboot ends immediately (during boot) in a BSOD (0x0D1 or 0x0D3??) from iaStoreA.sys!

 - I had to boot with F8 to delete "verifier.exe" settings.

 - Too i deactivated (not deinstalled) all drivers i don't need (mainly Acronis and virtualBox and WinCDEmu (i had installed meanwhile)

. i let the virusscanner active.) (BTW: I booted normally, but: F8-Mode was still active, i have to fix "OptionValue" in registry.)

 - I again set verifier.exe, as above, but now without Intel drivers too.

 - Got same BSOD from iaStoreA.sys!

- again verifier delete

- test with imdisk.exe -a -t vm -m X: -s 640M -p "/fs:ntfs /v:RamDisk /q/c/y" work, NO BSOD!

 - reactivated the drivers, boot

 - imdisk.exe -a -t vm -m X: -s 640M -p "/fs:ntfs /v:RamDisk /q/c/y" work, not BSOD

 - i set verifier.exe to check imdisk only.

 - immediately (during boot) a BSOD from.... iaStoreA.sys

 - Removing verifier.exe settings, all works well, no BSOD any more

 

Now it's your turn :-)

What was changed...?

booting in F8? Activating Verifier.exe?

 

 

I verified i had the newest drivers from Intel(11.7.0.1013 2012-11-19T12:10 ) ,Rensas(2.1.39, 3.0.23) and i always used imdisk 1.7.2.39 driver dated 2013-05-01T13:14

 

 

 

At http://www.sevenforu...rrupt-bsod.html

i used this :

Then, here's the procedure:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Edited by Jahonno, 17 May 2013 - 08:29 AM.

[Jahonno]

Should read : "i tried to find the driver which was causing the BSOD" :-).

Edited by Jahonno, 17 May 2013 - 10:08 AM.

[Olof Lagerkvist]

Thanks a lot for your tests and reports. I guess that something corrupts the memory pools in such way causing another driver to fail. I found and fixed something like that between 1.7.1 and 1.7.2. There was a problem found with verifier and/or dc2 (don't remember which one) that cause IRQL_NOT_LESS_THAN_OR_EQUAL when it tried to enumerate existing drives after the entire driver had been paged out. Maybe there is something similar here, but with some other causes. I am starting up debuggers and VMs now to do some further testing!

[Olof Lagerkvist]

I guess that this could be related to two different problems. One could be yet another IRQL_NOT_LESS_THAN_OR_EQUAL BSOD that was really supposed to have been fixed in 1.7.2 but for some reason was missed. There will soon be a 1.7.3 out that corrects this problem as well.

 

The other problem could more likely be related to something reported by another user about a year ago. I found an e-mail from 28 March 2012 about a SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION BSOD. This particular user found out that this BSOD only seems to occur when driver verifier is active, even if it is not monitoring imdisk.sys. From what I can see of that e-mail conversation, we did never really find out what caused this. By that time, I was unable to reproduce this problem but I seem to be able to do that now, for some reason. I also see the exact same behaviour as reported back then, BSOD with driver verifier active but no problems without. Strange.

 

A closer look at the BSOD stack trace reveals that ImDisk is attempting to complete an IRP sent from Volume Mount Manager. Generally, ImDisk does not respond to such IRPs. But this particular one, IOCTL_MOUNTDEV_QUERY_DEVICE_NAME, has been added just to keep some applications such as defragment tools and similar from bailing out completely when they expect mount manager interaction for all present disk volumes. For some reason, Volume Mount Manager seems to send an invalid IRP in this case. This could very well be caused by the fact that ImDisk does not follow Mount Manger integration design specification, not even close to. It is however okay to not interact with Mount Manager at all, which proves to be correct since I can remove the handling of this IOCTL completely and verify that everything then works correctly even with driver verifier active. So, best thing would probably be to remove this IOCTL handling altogether. It could possibly break compatibility in some other places, but it should at least not cause BSODs.

 

At least, I would hate to solve this in some way like "skip handling this IOCTL only when driver verifier is active" or something like that. That would feel entirely bad and wrong in all possible ways. So, I will try to find out something better. Did you in any scenario see this BSOD without driver verifier active at all?