(In the mean time I had to deal with yet another SNAFU – no electricity since yesterday afternoon, turns out that the supposedly "green" and so-called "social" provider simply terminated my contract for no obvious reason and with no warning whatsoever... :shock: I tried to reach them repeatedly but all I can get after 15 minutes of hearing silly waiting anouncements and a cringeworthy ear-worm melody is a clueless operator who does not have access to any information, and I had to repeat everything twice screaming a the top of my lungs cuz' their phone line was defective... My neighbour was kind enough to let me plug a long wire in his apartment, but mine is no longer heated, the temperature is 17.4°C right now and going down, and I'm writing this in near darkness, with only a desktop lamp as a source of light for the whole apartment... FUUUUUUUUU...
)
The driver/has been removed or partially removed already.
But the double command I quoted is supposed to remove it properly then re-install it, isn't it ?
So, I finally managed to get the system working again by :
– restoring the registry's three main files from RegBak as you advised,
– and restoring each file found in "LastGood" to its corresponding location (System32, System32\drivers, and SysWOW64), so as to minimize the inconsistencies with the older registry.
Then I proceeded to reinstall the updated Intel graphic and storage drivers, and reboot right away, and there was no issue this time. (I didn't attempt to re-install the Samsung driver, don't want to risk going trough that mess again for no obvious benefit.)
Before that I tried what was my first idea, it was a painstaking process and it failed miserably, I'd like to know why.
With WinHex (from that same live environment) I extracted an image from the NVME SSD Windows install and the small "system reserved" partition. Then I copied both images to the corresponding partitions (exact same size) on the SATA SSD. (The tricky part is that the system kept writing on both partitions, or prevented some system files to be overwritten, so in order to get a perfectly accurate copy I had to first disable the MBR by replacing "55 AA" by "FF FF", then unplug the SATA SSD, then re-plug it, then proceed with the image transfers, then thoroughly verify that there were no differences, and at the end restore the valid MBR code... I spent all evening doing this, which would have been trivial if there was an easy way to prevent Windows from mounting and accessing a particular storage device, which is the default behaviour with most Linux distributions – unfortunately, as I mentioned earlier, I was unable to boot from a Linux USB drive or DVD on this computer. WinHex does have an option to write-protect a device, but then it refuses to write on it itself, so it defeats the purpose in this case.) Then I removed the NVME SSD (at first I disabled its MBR as described above, then I physically removed it, the result was the same in both cases) and attempted to boot from the SATA SSD which now contained a bit-perfect copy of the Windows 7 install from the NVME SSD. And I got this error :
View attachment 409999
Meaning, I would guess, that the system was somehow expecting to complete the update process, and was expecting to complete it on the specific device on which it was started, which I wasn't expecting. And whatever happened at each startup probably reverted any registry fix made by Dism in the meantime.
Here are two log files generated during the failed update of the Samsung NVME driver :
View attachment 410000
View attachment 410001
One line in particular seems to corroborate that hypothesis :
"Error code 0x3FD: Impossible de créer une sous-clé stable sous une clé parente volatile."
If I understand this correctly, the whole sub-hive (if that's the right term) pertaining to storage controllers was considered "volatile", and it couldn't proceed to apply the required modifications, but it must removed something somewhere anyway, and then wasn't able to do a proper rollback. Does that make sense
technically ?
I haven't had a new BSOD yet (usually it happens after a 3-5 days session and several hibernation / wake-up cycles), but I still have that long running issue (which started right after I migrated the system from the SATA SSD to the NVME SSD) of abnormally long wake-up time from hibernation : today, according the the value found in "Diagnostics-Performance" in "Application and services logs", it took 184 seconds ; on November 1st it took 294 seconds, sometimes it's even more. With that supposedly blazing fast (and quite expensive) device I expected wake-up times to be almost instantanous, it doesn't make any sense, and I have no idea of what it's doing while the storage device activity LED is blinking frantically ! (The condition of the device seems perfect, according to HDSentinel.) I'll have to create a new thread for this as it's mostly unrelated.
