autoconv.exe problem

Hello,

Not sure if it’s the right forum to post, sorry, if it’s not.
I’ve got problem converting a FAT32 volume into NTFS using autoconv.exe.
The environment is quite unusual:

  • Windows 7 x64, some custom stripped version (for now assume that there is everything that needs to be in order to convert a volume)
  • Single HDD, two volumes, both FAT32, no separated 100MB boot volume, boot files and OS on \Device\HarddiskVolume1
  • autoconv is configured ro run as autocheck autoconv \Device\HarddiskVolume1 /FS:NTFS
  • Volume Dirty bit is set

autoconv tries to check volume for errors but cannot saying that it cannot open \Device\HarddiskVolume1 for direct access.

I need to get this volume converted by any means. There is something specific to this OS or hardware because on other machines or OS-es the same scenario works fine.

So first I checked that there is no any 3rdparty drivers and removed some unimportant filters.

Then I debugged autoconv.exe and found that first autoconv.exe successfully opens \Device\HarddiskVolume1 with SHARE_READ flag and reads some info including dirty bit. Then it opens the volumes with SHARE_READ | SHARE_WRITE flag and tries to check volume for consistency, this time it fails with error STATUS_SHARING_VIOLATION. I tried to change the flag in the debugger and in this case autoconv is able to open the volume and start checking.

So the first problem is how do I find who opened the volume with incompatible share flag?

I traced every reference count increment for \Device\HarddiskVolume1 object and some other volume related objects, I still analyzing the log, there quite a lot of records. Is there a faster way to find this? Does every “open volume” call go through some volmgr!xxxOpenVolume?

Maybe I will be able to find something but I doubt, I’ve already removed some unimportant filters including OS filters, there is almost nothing left except for volsnap, volmgr, fastfat and couple of system filters. So even if I find that volsnap is the one who uses incompatible flags, what I do next? Debug volsnap and try to understand why it’s doing that? Not an one week work.
It looks like I cannot disable volsnap on Windows 7. As far as I remember volsnap was a filter driver in previous versions of Windows.

Anybody knows how to disable volsnap in Windows 7? I kind of thinking volsnap is the one I’m looking for. By the way there is no reference to volsnap snapshots in the registry and no “System Volume Information” folder.

So what do I do?
Any suggestion work, I spent too much time on this problem already.

thanks!

Forgot to say - I logged every NtCreateFile/NtOpenFile call as well in that long log.

Found the problem.
It’s crashdmp.sys who opens a volume and never closes it. autoconv.exe later uses incompatible share flags and fails to check the disk. Found couple of MSDN KB articles about bugs in crashdmp.sys and available hot fixes, but they all are about Vista. Looks like crashdmp does not like much some boot 8GB FAT32 partitions.

After fastfat.sys debugging turned out that the fastest and easiest way to find who opened a volume first is to break at nt!IoSetShareAccess.

bp nt!IoSetShareAccess “rr8; kb; r $t0 = r8; gu; !fileobj $t0; gc;”

worked great.

There were not so many calls.

crahsdmp.sys is hardcoded at startup. Looks like removing the driver file does not break the boot process.