Need help troubleshooting an INACCESSIBLE_BOOT_DEVICE problem

  • Thread starter Thread starter Robert Stankey
  • Start date Start date
R

Robert Stankey

I've written an installation program that uses the Setup API functions to
install a couple of drivers I've created that in a storage driver stack
(one is a bus filter, the other a disk filter driver). The driver works
for either W2K or W2K3.

As part of my testing, during the installation I deliberately power off the
machine and restart it. On a couple of occasions I get a bugcheck 0x7b
immediately after you start to see the Windows splash screen. Rebooting
the box only causes the bluescreen again.

Before attempting the next round of tests I installed a dual-boot setup
with NT 4.0 being the first partition and W2K3 being the second. Once
again I start the installation on W2K3 then power off the machine. When
the recurring bluescreens happen I boot into the NT 4.0 partition to look
at both the Registry and System32\drivers directory. Past experience has
shown that if the "UpperFilters" or "LowerFilters" key defines your driver
yet the driver is not in the drivers directory you will get the crash. In
this case the Services Registry key is present and has all of the required
entries (ex. ImagePath, ErrorControl, etc). The drivers are also located
in the 'drivers' directory.

Next, I attach a kernel debugger and reboot into the W2K3 partition.
Strangely enough it boots fine with no problems! I've tried this scenerio
of power off/recurring crash/boot into NT 4.0/reboot into W2K3 at least 3
times now with the same results.

Any ideas? Does the boot process somehow examine the contents of other
NTFS partitions and somehow "clean things up"? Using the kernel debugger I
can run a !drivers command and don't see my bus filter driver loaded so I
suspect that is why the crash is happening but I don't know why the OS
can't load it even though the driver is present. What kind of information
can I gather by trying this with a checked build? Without a checked build?

Thanks,
Bob
 
I've written an installation program that uses the Setup API functions
to install a couple of drivers I've created that in a storage driver
stack (one is a bus filter, the other a disk filter driver). The
driver works for either W2K or W2K3.

As part of my testing, during the installation I deliberately power
off the machine and restart it. On a couple of occasions I get a
bugcheck 0x7b immediately after you start to see the Windows splash
screen. Rebooting the box only causes the bluescreen again.

Before attempting the next round of tests I installed a dual-boot
setup with NT 4.0 being the first partition and W2K3 being the second.
Once again I start the installation on W2K3 then power off the
machine. When the recurring bluescreens happen I boot into the NT 4.0
partition to look at both the Registry and System32\drivers directory.
Past experience has shown that if the "UpperFilters" or
"LowerFilters" key defines your driver yet the driver is not in the
drivers directory you will get the crash. In this case the Services
Registry key is present and has all of the required entries (ex.
ImagePath, ErrorControl, etc). The drivers are also located in the
'drivers' directory.

Next, I attach a kernel debugger and reboot into the W2K3 partition.
Strangely enough it boots fine with no problems! I've tried this
scenerio of power off/recurring crash/boot into NT 4.0/reboot into
W2K3 at least 3 times now with the same results.

Any ideas? Does the boot process somehow examine the contents of
other NTFS partitions and somehow "clean things up"? Using the kernel
debugger I can run a !drivers command and don't see my bus filter
driver loaded so I suspect that is why the crash is happening but I
don't know why the OS can't load it even though the driver is present.
What kind of information can I gather by trying this with a checked
build? Without a checked build?

Thanks,
Bob
Click to expand...

It is possible that the problem doesn't have anything to do with the
drivers but is instead a file system problem. Check the parameters on
the stop 7b and see if that is the case. Also you can boot to recovery
console and run chkdsk /p and see if it resolves the issue.

Leonard Severt

Windows 2000 Server Setup Team
 
It is possible that the problem doesn't have anything to do with the
drivers but is instead a file system problem. Check the parameters on
the stop 7b and see if that is the case. Also you can boot to recovery
console and run chkdsk /p and see if it resolves the issue.

Leonard Severt

Windows 2000 Server Setup Team
Click to expand...

The third parameter to the bugcheck is 0xC0000034, and the second parameter
is to a UNICODE_STRING. I can't remember the exact name, but it does
reference one of the partition names in the boot.ini file. I'll try the
'chkdsk /p' option the first chance I get.
 
Back
Top