FDISR BSOD halt “inaccessible boot device" stops crash recovery.

Hi all,

Been using new FDISR for a few months, after you guys helped me sort out instructions, poor help and terminology, at the outset. It worked perfectly for me a couple of times in real life. Also using Shadow Protect but haven’t shelled out money for full image recovery CD yet.

Mainboard: Gigabyte M61PME-S2. CPU: AMD 64 5000+ X2 M2. RAM: 2 GB KVR DDR2 (1 stick, in single mode). System drive is almost new 80 GB Western Digital SATA 1 drive owned 2 or 3 months but just installed. Backup drive older (in warranty) 80 GB EIDE drive (to be replaced asap w/Western Digital 250 GB SATA 3 via WD customer loyalty program). OS: W2K_SP4, fully updated via Windows Update.

Been getting tuned up and burned in, may have done something lately that caused my problem. Last action: Updated ACPI driver in Windows Device Manager, from Uniprocessor to Multiprocessor following Microsoft KB guide, a few days ago. Several full computer boots and reboots since then w/no problems.

Woke up to a totally unexpected crash recovery problem, this a.m.

Shut down last night after a full box virus sweep with KAV, from OA AV+. This a.m. when I switched on, my box went thru usual post stream, passed FD preboot display, entered Windows boot sequence. In W2K there is a fast progress bar where you get to do F-8 to modify the rest of the boot, then it defaults to a Real Mode Windows logo splash screen with an actual Real Mode progress bar. Finally it switches to Protected Mode to complete booting Protected Mode drivers and services. A flicker or 2, then the standard Windows cobalt blue desktop marks the transition with a single centered but movable cursor. That’s the first visible evidence of the Protected Mode process.

This morning, everything went normally until the end of Windows Real Mode, then I got a sudden BSOD with stop message “inaccessible boot device”! WTF! This is a first ever.

Did this 3 times to be sure I had a repeatable fault, documented sequence. Then tried to boot to rescue image with F1 -> yes. Preboot display appeared, functioned correctly. But during continuing Windows boot sequence, exact same thing happened! So neither original nor rescue images are accessible. I’m now on my elderly backup ThinkPad laptop.

I didn’t think this was supposed to be possible with First Defense. The only way this can be happening is that the very first 32-bit executable file in the Protected Mode part of the of the Windows boot sequence is missing or corrupted. That file also must not be in the rescue image, but in the MBR, or FD should have saved this. From what is happening, First Defense depends entirely on a completely intact MBR. Is this true?

After reading a lot of tech forums, I seem to have 3 possible options: (a) reboot the machine again, do F8 during the fast progress bar, then choose “Go back to the last known good version; (b) Boot from Burrows UBCD4Windows, and do chkdisk/MBR to replace the MBR (which will blow out the First Defense install) and (c) long shot—swap out the RAM, which has reportedly been known to cause such MBR access problems.

But before I do anything else to that machine I want to ask for ideas from the crash recovery go-to guys, with great respect and appreciation from the last time you educated me,

Pinky

 

Hi Pete,

Basically, I was trying to move a new dual core motherboard/CPU upgrade in on my unchanged system drive, through a Microsoft recommended hardware profile modification, right from the MS Knowledge Base. It changed the ACPI driver/HAL—from Uniprocessor PC to Multiprocessor PCI, and also installed a different version of ntoskrnl.exe. in Root/System32/… It worked for several days, through several reboots. As far as I know that BSOD stop message basically means the MBR is corrupted or inaccessible, but it wasn’t initially. I assume the Microsoft procedure made no changes to the system drive boot sector, and it didn’t mention any.

All the tests I did with WD Diagnostics and HCImemtest, etc, found no errors. Rescue attempts from external CDs failed as well. Chkdisk from the rescue boot cd couldn't find the C drive boot sector either, nor could the Repair Reinstall option on the Microsoft OS media CD. The short of it is, after trying all suggestions, I finally had to delete the system partition, fresh install the OS and am now in the middle of installing the rest of the system drive software I use.

I was shocked that FD didn’t work. I thought this was the exact thing that shouldn’t happen! I know First Defense is only as robust as the system drive MBR, but this is a new WD SATA drive and I still have no clue as to a possibly corrupting event.

I still can't pinpoint why the boot to the Rescue area failed at the exact point where Windows switches from the Real Mode part of the boot to the Protected Mode part, for both images. I have a hunch thats where the real secret of this is, but I don't have the technical depth in the Windows boot process to take it any further. Can you bring in anyone with this skillset?

I do have a Shadow Protect full image on the backup drive, but that image is of my previous hardware profile, which no longer relates to my new dual core hardware and now correct HAL and ntoskrnl.exe. Wouldn't that just install a new instance of the same problem? Seems like I need to finish the system drive software installations, finish the hardware build out (replace the aging Data/Backup drive) and do a new Shadow image for all to be synchronized. Wouldn't that be better at this point?

Also to present the issue for FD users, how does FD interact with a major hardware upgrade? What’s the best way to proceed? I now guess it would first of all start with verifying the good condition of all drives and replacing any dubious ones before even getting underway. Then with a mainboard/cpu upgrade, to immediately copy the new system image to the rescue area after the very first successful boot into the new hardware profile. Can anyone verify that?

This feels like an absurd blind spot. As I said back in the beginning, I’m a novice with high tech crash recovery and backup recovery. I hate getting wiser in my usual historical style, by stepping in the bear traps along the way!

Pinky

 

Re: FDISR BSOD halt “inaccessible boot device" stops crash recovery.

that's a good Q, not sure that has been asked before.
you are obviously experienced user: be interesting how this pans out.
Maybe Todd will appear.
Pete might be able to contact him.
Not sure of answer, maybe similar issues with HW profile or loading drivers ?? if restoring. MBR not specifically a FDISR issue for some time as now installs to partition boot record, but new HW maybe a prob...just speculating.

Hey whats wrong with that lol that;s my tried and true method dang it...is there another way..?? .

 

Changing from single processor to dual core by changing the HAL is not always as sucessful as expected.


If you have access to another computer buy that SP recovery disk take a full image before you mess around any more. - you may be able to fix it later or use VMconverter image to VM conversion


I fail to understand why FD can be at fualt here this sounds like your hardware migration is not as complete as expected ...... can the remaing steps be completed from a LiveCD?

what is the actual stop error?

 

Re: FDISR BSOD halt “inaccessible boot device" stops crash recovery.

yes..

 

Thanks guys.

@Longboard

True, I'm not a newbie; I'm so old my career was in high blower before Computer Science was a major, so I have huge peaks/valleys of knowledge detail, never mind interest

@starfish

Thanks but I'm a W2K_SP4 user and don't do VMware. Tell me how this situation could be improved by importing an old hardware profile onto my new hardware?

@peter2140

I'd love to hear from Todd. Trying to figure out exactly where Windows boot process went south, and I think he'd want to know too. I don't think this is about bad hardware. Rather about hardware profile, HAL, location of bootfile executables.

Hola Todd?

Pinky

 

I'd try shadow protect to migrate to new hardware using HIR

but VMconverter can do P2V and V2P conversion. I have done P2V many times with few problems

 

Trouble is I have zero experience with Shadow Protect except for creating one more-or-less experimental backup of my old system drive to my backup drive about 3 months ago. I don't even know what HIR means. I now see I should have updated it much more often than I did ... but, shoulda, woulda, coulda, eh? I now know I should have been much more proactive about using Shadow Protect. I was still stuck in some old mindset of denial about backup--the biggest bear trap of all. My bad!

I've had no interest in VMware, still don't, so no knowledge about. I really want to figure out what went wrong with FDISR and whether I want to rely on it from here on, and how to team it with Shadow Protect.

Pinky

 

Well, I did get a brand new 500 GB WD SATA drive installed and copied my not-quite-out-of-warranty 80 GB WD EIDE data drive into it, so I don't feel quite so vulnerable. Now my REALLY hard to replace data is on two drives. Next I'll get an external USB Drive and backup both the system and data to that as well, and I'll feel pretty safe. The next thing I guess I need to get is the Shadow Protect CD and learn something about image management.

I don't think this is a W2K problem and I don't think the MBR, and probably really not FDISR either. FDISR is actually just a cute dual-boot system where the preboot screen lets you boot into a clean image, but it had done the job and started the actual Windows boot. The boot didn't complete. I've had this switchover failure before in another application, trying to create a bootable pen drive. It was a similar situation, a custom preboot program to preselect a boot image. When this switchover fails you can't go ANYWHERE. I never got to the bottom of that one either, but I think its because I focused on the preboot program and I should have been in the Microsoft KB.

If this had broken down in the MBR I would have gotten a different error message saying it couldn't find an operating system. Windows had started and the MBR was out of the picture. This went south well into the Windows boot process, specifically when it tried to switch from the real mode executables to the Protected Mode. Those drivers and executables are all in the Windows/System32 folder. If that switchover fails you've lost connection with your boot drive, hence the BSOD and "Inaccessible boot device" STOP message.

I'll post back if I find anything helpful. Incidentially, re: W2K, its interesting in the Online Armor forum, the parade of betas has all the XP and Vista users totally wrapped around the axle, whereas its mostly gotten better and better for me! 3_170 even has RunSafer working in W2K_SP4. One thing people don't realize (and I'm sure M$ keeps quiet) is that SP4 has been issued more than once, along with the SP4 Rollup, plus updates, and in the process W2K has had a lot of the best parts of XP added to it, without all the aggravation of active registration.

Pinky

 

Hi Pete and all,

I beg your indulgence for a long post with info many of you already know. I’m pretty sure my Original Post (OP) is reporting a failure of the Windows Boot Process and I’m hoping Todd will show and explain how FDISR could be involved. I just went to HorizonData’s support web Forum and knowledge base and discovered both to be populated only by bloody HorizonaData marketing trolls. Todd could show up here to explain some things.

Windows boot process summary.

MBR contains first stage Windows boot loader. Due to tiny size, code in the MBR just loads another sector from the disk that contains additional bootstrap code. This might be the boot sector for a partition, but could also be a sector that was hard-coded into the MBR code when the MBR was installed. Some of this to follow only can happen in the 1st 640 KB of RAM, some in the 1st 1 MB, some above in the 1st 4 GB of RAM. A ton of dancing around happens, noted below.

For example the MBR created for FDISR includes or points to code for the FDISR Preboot display. The MBR code plus code loaded in step 2 then reads a file containing the second stage of the boot loader. In Windows this is c:\NTLDR. If step 2 fails in Windows you get messages like “ ‘NTLDR is missing’, ‘Invalid disk, replace and hit any key’, even, ‘no operating system’ ”. The stage 2 code then reads a boot configuration file, boot.ini in Windows. It then presents boot choices to the user or simply goes ahead in a single-boot system.

At this point boot loader code sequences to initialize a kernel. In Windows, some kernel start-up code from the kernel image itself may actually by embedded in NTLDR. After doing several initializations, NTDLR loads the kernel image from file c:\Windows\System32\ntoskrnl.exe and jumps to the kernel entry point.

DANCING AROUND: An image for current Windows kernel does not fit into 640K of RAM available in real mode. The multiprocessor NTOSKRNL.EXE kernel is 1.63 MB. But boot loader must run in real mode to call BIOS routines for reading from the disk, since kernel is obviously not available yet. The solution is so-called “unreal” mode. Not a true processor mode, but a sort of hacked-up, paging-like technique where programs switch back and forth between real mode and protected mode to access memory above 1MB while still using the BIOS. At the end loader has poked the kernel into memory, but has to leave the processor in a real mode exit when done. Next is jump from “Boot Loader” to “Early Kernel Initialization”, when the kernel initializes the next processes in protected mode.

HERE IS WHERE I THINK MY PROBLEM HAPPENED. Any insight from you, or Todd?

Windows Kernel Initialization:

C:\NTLDR reads C:\Boot .ini, presents boot menu to user. For a single boot system, the FDISR preboot menu simply points the single boot process to the preferred image. It loads ntoskrnl.exe; hal.dll, bootvid.dll, and the boot start drivers.

As a result the boot process switches to protected mode and enables paging.

Ntoskrnl.exe initializes the kernel data structures, non boot cpu(s), object manager, i/o manager, and starts C:\Windows\system32\smss.exe, which initializes the registry using the hives in C:\Windows\system32\Config. It also starts C:\Windows\System 32\Csrss.exe and C:\Windows\System32\Winlogon.exe. Winlogon spawns Services.exe, which starts all of the Windows Services, and Lsass.exe, the local security authentication subsystem. The classic Windows login dialog runs in the context of Winlogon.

Pinky

 

Thanks, it was clarifying about several issues, especially about being able to use FIXBOOT and FixMBR from the Recovery Console or a live CD.

I think I have a whole narrative now. The "original" FDSIR image is, after all, only the current bare metal system install, normally always in use by default when no action is taken at the FDISR Preboot. The "rescue" image is some earlier version of it, and in this case it would have been an image of the wrong old hardware. Not that it ever mattered.

If one has a boot failure of the kind I experienced, where Windows has appeared and run through all its real mode moves, the next failure HAS to be a Windows failure because there is nothing for First Defence to do in any event. Once ANY image has booted and Windows has made any appearance in ANY mode, First Defense has gone home from the party. So the 1st failure HAD to be a Windows failure of a kind that First Defence is not designed to intervene with. And it happened several times as I verified it. The first thing to happen after the real mode boot process completes is the awakening of the Windows kernel in protected mode and that did not happen, hence a BSOD with the "inaccessible boot device" oxo7b stop message.

So I now think the attempt to do this dual core upgrade has to be the origin of the corrupt boot process, even though it was straight from the MS Knowledge Base. Even thought I installed the new chipset drivers there was undoubedly wrong stuff left around. If I ever have it to do it again, I would do a repair reinstall from the retail Windows CD. It would have been far faster than this. Then, of course, one is reinstalling FDISR as well. So that's the answer to the question, how does FDISR interact with hardware upgrades.

Pinky

 

Re: FDISR BSOD halt “inaccessible boot device" stops crash recovery.

Nice posts pink emu exactly where does one find a pink emu

Hhmm....even MS might make a 'mistake' now and then

?? I'm not sure that an FDISR snapshot would restore to different HW: certainly has restored for me to same HW.

 

Thanks! The rare pink emu posts in the Online Armor forums at Tall Emu, trying to get a little respect for a fully updated W2K_SP4!

Hmm. Well, the truth is I started with a link in a tech forum to an archived MS KB article that was possibly later updated. There are a ton of archived articles out there in Tech Forums, and its easy to get outdated information in an area of fast moving changes. So the advice is, go DIRECTLY to support.microsoft.com for answers to MS questions. Even then you find KB articles with uncomfortably old "last update" time/date stamps. In the end you always "pays your money and takes your chances" don't you? It ain't a risk-free world. I will say this: It was after reading the latest info I could find on support.microsoft.com that I decided the actual best course of action to mate up a new board and cpu with an existing system drive, was to do a repair reinstall directly from the Windows OS media disk.

I tried it and the "rescue" area boot gave exactly the same response, but the trouble is, thats exactly what you'd expect if this was basically a Windows boot process that became corrupted at the bare metal level.

FDISR starts a snapshot that does not correspond to the installed hardware, but in my case it happened to be the same brand of motherboard with the same brand bios and it was the same hard drive and MBR, so it might very well go through all the real-mode-and-bios originated boot process, but soon as it tries to switch to the Windows protected mode steps, the imaged C:\NTLDR, which has some of the uniprocessor kernel code embedded, is going to try to call the multiprocessor kernel actually now sitting in WINNT\System32. In either case, whether the kernel is corrupt or not, NTLDR can't talk to ntoskrnl.exe and the "inaccessible boot device" BSOD is the only option left for Windows.

Seems to me if there is a totally different motherboard and bios, the most likely difference is the Windows boot process simply has a higher probability of failing earlier, in the real mode steps, with a similar result. If the boot process can't get to NTLDR then maybe you get the "NTLDR is missing" message from the bios. If it gets to NTLDR you get the "boot device inaccessible" BSOD. Or maybe you get the BSOD immediately, depending on how smart the new bios is.

Pinky