Inaccessible Boot Device - help with diagnosis

Well well well, I've fixed it myself.

Definitely, absolutely definitely, a Mickeysoft update had broken the installation - which is by far and away the most common cause of "INACCESSIBLE BOOT DEVICE".

This keeps my record of fixing broken Windows installations, whilst keeping all my personal files and installed applications ni tact to 100%. This one was a little more challenging, but hey, I got there a lot quicker than I would have if I formatting the disk and reinstalled windows.

Just for a laugh, I logged a case with the Mickeysoft clowns and also the PC's vendor, Dell.

Mickeysoft were very funny. I played along for a while but as soon as I started asking some nice technical questions about the UEFI boot process it all went quiet and I was "escalated" to a level two clown. Who actually was worse than the first line of defence.

Eventually, I forced Mickeysoft into singing their "you need to re-install windows" national anthem. Which they always do once you challenge the nonsense they come out with.

Meanwhile, Dell tried to blame it on a "loose connector" on the disk drive. I had a job convincing them that this was unlikely since I'd managed to copy all my personal files off the disk without any errors and wasn't it clever how the connector managed to fail at exactly the same point in the boot process? However, they then changed their opinion to it being a worn sector on the disk. ROTFL.

I used to write filesystems for a living - I'm the author of the FAT filesystem driver for OSPLUS/OS21. So these kind of excuses always make me laugh. Given what they do, you'll be amazed at just how reliable disk drives actually are. I've only had a couple go on me, and it's usually obvious when they do.

It's quite shocking that Mickeysoft can get away with effectively logging into people's computers and trashing them. Imagine if I did that to Mickeysofts computers. That would be illegal right?

Then we come to the "experts" on forums such as these who think they know what they are doing, but actually don't know an awful lot at all about Operating Systems, Filesystems, UEFI boot or pretty much anything else.

I'm sure they've got good intentions, but actually, I think they only help to protect Microsoft from their dreadful software. I bet Mickeysoft love them.

First of all, they hijack almost every decent post, by regurgitating, like a broken record, the usual blurb. Such as try scandisk, try bootrec, try, this, try that, without actually reading let alone understanding the issue the original poster has described. This is dangerous. It may well help a few people, but it may also help to trash just as many perfectly rescuable installations.

Next, these people help Microsoft by obfuscating the issues - by blaming all manner of things, such as broken connectors, worn sectors, anti-virus software and pretty much anything else apart from Mickeysoft's dreadful software and attitude towards it's customers. I believe this conceals the truth that most installations are broken by poor, broken software.

When you challenge these people, they either vanish or they get all upset and start threatening to boot you off. "We don't want your sort here. You know what you're talking about..."

Mods - feel free to punt me off here. These forums are about as useful as a chocolate teapot.

Really Sorry you're so upset Greg, but I'm afraid you clearly don't understand this problem.

You provided a number of solutions which, to somebody who understands what is going on, are clearly irrelevant. (I've got 30 years experience developing Operating Systems, device drivers, filesystems, etc. I'm the prime developer of an RTOS with around 1 billion units in the field....)

For example: One of your solutions was the usual bootrec /fixmbr stuff.

Had you read, and understood my post and if you understood anything about what's going on, you'd know that my computer is UEFI boot, and that stuff it totally irrelevant - on top of the fact that its got as far as loading winload.efi and is **way** past the point at which MBRs and boot records are going to be of any use. I also told you that it was booting bootmgfw.efi OK and that in turn was loading winload.efi - which again is *way* past any of the bootrec stuff.

For example: You told me how to make some installation media.

This is not a solution. It's a diagnostic tool. Further, since my post clearly showed me modifying the filesystem offline, it's obvious that I already had some other means of booting into a recovery command tool. But the key point here, is this is not a solution, and it certainly doesn't answer the questions I asked.

For example: You told me to run a surface scan on my disk. Now that's a good waste of several hours since I already told you the disk is working fine.

For example: You told me to run safe mode. Had you read and *understood* the original post, and you knew your stuff, you would have known that the boot process isn't getting as far as being able to select safe mode. Safe mode simply selects a different control set in the registry - if you don't get that far in the boot process, then clearly you can't select safe mode.

But worst of all, you told me, and thousands of others to:

"Better yet do the vastly superior Clean Install Windows 10 following the steps in this link to delete all partitions down to Unallocated Space to get it cleanest"

Did it ever occur to you that I may want to keep the data on the disk, or the installed applications?

For heaven's sake!

It's amazing how so many issues in Windows can only, apparently be solved by, "reinstalling windows". That's a true measure of the reliability of an OS isn't it? Customers really, really, don't want to re-install Windows every time Windows corrupts itself. They want an OS that is reliable and never does that in the first place!

Are there any *true* experts on here with detailed knowledge of the boot process, and in particular, working knowledge of the mechanisms by which the boot process can generate INACCESSIBLE BOOT DEVICE at the point I've described in the original post?

Or are there any better forums, where real experts live, rather than people telling you to reinstall windows and fix MBRs all the time? I suspect I'm wasting my time here! :o)

That's a really disappointing reply.

You haven't even come close to answering the question, or helping in any way, to the point where I'm wondering if you've even read, let alone understood  what I've said. Some of your solutions are clearly not relevant, and if you think they are then you have no understanding of Operating Systems and the boot process.

All you are doing is obfuscating the issue with a whole pile of useless, "try this", "try that" type solutions that, frankly will never work in a million years.

I've described what I've done to diagnose where, roughly, in the boot process things are going wrong. Somewhere after winload.efi loading the kernel (ntoskrnl.exe), the HAL, (hal.dll) and the registry's system hive, but before smss.exe is loaded.

So what happens around this point, in detail, to generate the INACCESSIBLE BOOT DEVICE stop?

How does the boot process decide which driver to use to talk to the disk? What registry entries does it look at in doing this?

If you don't know, leave it to somebody who does.

Please, please, please do not post random troubleshooting "guesses" that are totatlly useless, and sound like a broken record.