R
Rabidgoalie
Here is some background information on the problem that I just got done fixing, after about seven hours of work including a call to Microsoft's support line where a nice lady tried everything she could think of to help. She offered several solutions to my problem that I didn't find online when I was searching this morning, so I will supply those below just in case it may help someone else. So on to the explanation of the problem that I have been facing all day.
TL;DR
I tried to update my storage controller drivers using the correct drivers downloaded from AMD, as instructed by the Control Panel dialog, and something went horribly wrong and my system wouldn't even boot in Safe-mode. I had to use the recovery command prompt to undo the damage that was done to get my system back. But, my system IS back. Skip the long version below and read everything past the dashed line.
Detailed Explanation
For the past few days, my Windows 10 system has been informing me that there was a problem with the updating feature, and that there was a fix to my problem. When I pressed the pop-up in the bottom right corner of the screen (you all know those pop-ups), it took me to the 'Control Panel->Updates & Security' page and there is a button that says 'Fix Issue'. I pressed that button and after some time passed, a dialog was displayed to inform me that the update couldn't continue due to the fact that my system uses drivers that are incompatible. I needed to update my drivers to version 9.2.0.105 or later. So, off I went to AMD's website to download those drivers. I didn't want AMD's RAIDXpert Utility so I chose to download just the drivers. These drivers are stated to be compatible with my X370 chipset, so I didn't feel I needed to worry.
With my shiny new drivers in hand I was off to the Device Manager to install them. The download isn't a .EXE file and doesn't have an automated way to install them. I unpacked the files with 7zip to my desktop and pointed the Device Manager to them to update the 'AMD-RAID Bottom Device', 'AMD-RAID Controller [storport]', and lastly the 'Standard NVM Express Controller'. That last one is where everything went wrong. I updated that with the new drivers because the message that I received in the Control Panel specifically made mention of the NVMe controller, so I naturally thought that this would need to be updated with this newer driver software from AMD. The drivers from AMD have a folder named 'RAID_NVME' so the drivers should be in there for the NVM Express controller but they don't appear to be the correct ones. I had Control Panel scan the sub-folders to find the correct .INF files for the devices, and there was no indication that anything was wrong until I restarted my computer and didn't even get the blue-screen-of-death. It would just attempt to start Windows and when it couldn't it would restart the system and give it another go. Then, finally, it would try to auto-fix the start-up problem. When that didn't work, I was taken to the screen with all of the troubleshooting options including the one that will allow you to restart with the option to go into one of the flavors of Safe-mode. There was no version of Safe-Mode that would start up, so my only option was to go into the Recovery Command Prompt (I'm not sure that is the exact name, but hopefully you know what I mean). That is where I was finally able to get my system back up and working in the state it was in before all of this started. No, I haven't updated all of those drivers and I am frightened to try now. But, below is the steps that I took to get my system back without having to wipe the main drive and reinstall Windows 10.
I'm sorry if this is really long, but I may repeat some information for clarity. That is why I included the TL;DR section above, to shorten this up a bit.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
The following commands were attempted fixes by bringing up the Device Manager (these didn't work for me, unfortunately, but they may help someone):
prompt> C:\Windows\System32\control hdwwiz.cpl
prompt> C:\Windows\System32\control /UserName Microsoft.DeviceManager
The following is the fix that worked for me (your mileage may vary):
Please read through the entire post. I know it is long, but I am trying to include as much information as possible to make this as safe as it can be. It is dangerous, though. I won't lie to you. If you do this wrong, you could do some serious damage that may force you to reset your system or even reinstall Windows.
My main drive is assigned the letter 'C' on my system, and I have quite a few other drives in RAID. Your main drive letter should be substituted for 'C' if it is different, and any other drive letters and paths should be changed to reflect your system. First and foremost, read the file "C:\Windows\INF\setupapi.dev.log" to find the drivers that where last updated. Hopefully, you will have a good idea what driver may be causing the problems. Save this to a USB flash drive to access this on another computer, if that is available. But in any case, save it to something that you can read back from. This file was invaluable in helping to figure out what driver package I needed to remove, and losing access to it would have been a disaster. In my case that driver package was OEM7.INF but yours will almost certainly be different. This file is somewhat cryptic and difficult to read. The entries you are looking for are most likely to be at the bottom. It seems to refer to the entire collection of files that make up a driver as a package. These files include the .INF file as well as the .SYS file or files. For my install, the driver package that was installed was referenced as OEM7.INF, but that is not the folder that holds the drivers files. This seems to be a label for the package, but I could be wrong. I am not an expert when it comes to drivers construction. The folder that holds all of these files seems to be referred to as a repository. I am going to use these terms below when describing the steps I took to recover my system.
Then execute these commands to find out more information and attempt a fix:
1)
prompt> notepad C:\Windows\INF\setupapi.dev.log
This will open notepad with the correct log file to read. This is going to take a little time to figure out, but I promise you the information is in there. Make note of all of the information about the driver or drivers that you believe may be causing problems. You will need this information not only to remove the driver, but to put it back if needed. The package I was looking for was named OEM7.INF once it was installed on my system, but the actual repository that it was saved in was named 'rcbottom.inf_amd64_C3117b26262da451'. This is the type of information that you will need to find in this file.
2)
prompt> C:\Windows\System32\Dism /image:C:\ /Get-DriverInfo /Driver
em7.inf
That command will provide you with the information on what that driver package provides, as well as the version number, so that you know you are getting the right driver. Reading all of the data that is supplied by DISM was really helpful in my case. I could see that this package was the new version and that it was 'boot critical'. This gave me more confidence that this was the offending driver package. I don't believe in having too much information.
3)
prompt> C:\Windows\System32\Dism /image:C:\ /Export-Driver /Destination:H:\WinX-NVMe
This command will back up ALL of your third-party driver packages. DO THIS! I don't care if you have to go and buy a USB flash drive...DO THIS! If you don't, you run the very real risk of losing your install. If I hadn't done this, the computer I am typing this on right now most likely would be receiving a fresh install of Windows 10. In the above example, I was saving to a USB flash drive with the drive letter 'H' and a folder named 'WinX-NVMe'. You will have to replace these with the full path to the location where you intend to backup these driver packages. My backup was almost 2GB in size, so make sure to have a fair amount of space for this. But, DISM will tell you if it runs out of space before the backup is completed so don't worry. Look into that folder once you are done with the backup. There should be a bunch of folders with really long names like the repository name that I listed above. They WILL NOT be labelled OEM1.INF, OEM2.INF, etc. That is why you have to read that log file carefully. To make sure that I had found the right repository to match my OEM7.INF package I used DISM to get the driver information and pointed it to the backup data with this command:
prompt> C:\Windows\System32\Dism /image:C:\ /Get-DriverInfo /Driver:H:\WinX-NVMe\rcbottom.inf_amd64_C3117b26262da451\rcbottom.inf
Again, you would replace the drive letter and the path with your USB flash drives letter and path to the backup files for the '/Driver' argument. But DISM printed out the exact same data that it did for the command in step 2 above. That way, I knew I had the correct driver and could put it back if I really needed to, and I did need to. Don't proceed until you have made sure that you have found the repository that contains the package that you are about the remove. You can't undo the next step otherwise.
4)
prompt> C:\Windows\System32\Dism /image:C:\ /Remove-Driverem7.inf
This is the scary moment, but remember, you backed up ALL of your third-party drivers and you should be able to reinstall this if it doesn't work. Find the actual driver directory in the 'setupapi.dev.log' file. As I said, it is long and cryptic, but it DOES tell you where the driver repository is at and what its name is. Mine was: 'rcbottom.inf_amd64_C3117b26262da451' and the .INF file inside that repository was named 'rcbottom.inf'. If you need to reinstall this for some reason, it should reinstall under the OEM*.inf repository that it did initially. Mine reinstalled to OEM7.inf when I needed to reinstall this package due to "PAGE FAULT IN NON PAGED AREA" errors that I received. This page fault error occurred after I uninstalled the OEM7.inf driver package the first time via DISM. But my system did start right up after I removed OEM7.INF. It was only after I restarted my computer that I started to get the page fault error. That is why you must back up those driver repositories. You never know...you just might need them. I did.
5)
prompt> C:\Windows\System32\Dism /image:C:\ /Add-Driver /Driver:H:\WinX-NVMe\rcbottom.inf_amd64_C3117b26262da451\rcbottom.inf
The command above will install the driver back on the system. When I needed to do this it installed back to the OEM7.INF package like it was before I removed it. I can't guarantee that this will be the case for you, but it did work for me. As stated above, you will need to substitute your systems information in the command. I included my command calls to give you a real-world example of what the command will look like.
In closing, I know that there were a lot of commands to issue at the command prompt, with a lot of arguments that have to be passed to DISM to get this to work. I attempted to keep things clear by quoting file and folder names, and using different formatting to call attention to important things. I apologize if it made this difficult to read. Also, I tried to remember all of the commands that I used, but it is possible that I may have made a mistake. I am going off of my memory after all. If something doesn't seem to work the way that I have mentioned, look up the page for the DISM tool and read that. Actually, you should do that anyway. Obviously you can get on the Internet, or you wouldn't be reading this, right? You should remove the driver package that is possibly causing problems only when you are sure that you have your backup done and you know where the driver repository that you are about to remove is located. So that way, you can put it back if need be.
This is dangerous! It can remove files that will force you to reinstall Windows 10 if done improperly. Only do this if you are already considering a fresh install of Windows on your system. It worked for me, but it may not work for you. If you do it wrong, it could cause more harm than good. But I hope that this will help someone fix their system and not require a wiping of Windows with a loss of your data. That sucks. If I have made any mistakes above, please post a correction below so that we can help others fix their system. Well, I have been at this all day and I am done now. Good luck!
Continue reading...
TL;DR
I tried to update my storage controller drivers using the correct drivers downloaded from AMD, as instructed by the Control Panel dialog, and something went horribly wrong and my system wouldn't even boot in Safe-mode. I had to use the recovery command prompt to undo the damage that was done to get my system back. But, my system IS back. Skip the long version below and read everything past the dashed line.
Detailed Explanation
For the past few days, my Windows 10 system has been informing me that there was a problem with the updating feature, and that there was a fix to my problem. When I pressed the pop-up in the bottom right corner of the screen (you all know those pop-ups), it took me to the 'Control Panel->Updates & Security' page and there is a button that says 'Fix Issue'. I pressed that button and after some time passed, a dialog was displayed to inform me that the update couldn't continue due to the fact that my system uses drivers that are incompatible. I needed to update my drivers to version 9.2.0.105 or later. So, off I went to AMD's website to download those drivers. I didn't want AMD's RAIDXpert Utility so I chose to download just the drivers. These drivers are stated to be compatible with my X370 chipset, so I didn't feel I needed to worry.
With my shiny new drivers in hand I was off to the Device Manager to install them. The download isn't a .EXE file and doesn't have an automated way to install them. I unpacked the files with 7zip to my desktop and pointed the Device Manager to them to update the 'AMD-RAID Bottom Device', 'AMD-RAID Controller [storport]', and lastly the 'Standard NVM Express Controller'. That last one is where everything went wrong. I updated that with the new drivers because the message that I received in the Control Panel specifically made mention of the NVMe controller, so I naturally thought that this would need to be updated with this newer driver software from AMD. The drivers from AMD have a folder named 'RAID_NVME' so the drivers should be in there for the NVM Express controller but they don't appear to be the correct ones. I had Control Panel scan the sub-folders to find the correct .INF files for the devices, and there was no indication that anything was wrong until I restarted my computer and didn't even get the blue-screen-of-death. It would just attempt to start Windows and when it couldn't it would restart the system and give it another go. Then, finally, it would try to auto-fix the start-up problem. When that didn't work, I was taken to the screen with all of the troubleshooting options including the one that will allow you to restart with the option to go into one of the flavors of Safe-mode. There was no version of Safe-Mode that would start up, so my only option was to go into the Recovery Command Prompt (I'm not sure that is the exact name, but hopefully you know what I mean). That is where I was finally able to get my system back up and working in the state it was in before all of this started. No, I haven't updated all of those drivers and I am frightened to try now. But, below is the steps that I took to get my system back without having to wipe the main drive and reinstall Windows 10.
I'm sorry if this is really long, but I may repeat some information for clarity. That is why I included the TL;DR section above, to shorten this up a bit.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
The following commands were attempted fixes by bringing up the Device Manager (these didn't work for me, unfortunately, but they may help someone):
prompt> C:\Windows\System32\control hdwwiz.cpl
prompt> C:\Windows\System32\control /UserName Microsoft.DeviceManager
The following is the fix that worked for me (your mileage may vary):
Please read through the entire post. I know it is long, but I am trying to include as much information as possible to make this as safe as it can be. It is dangerous, though. I won't lie to you. If you do this wrong, you could do some serious damage that may force you to reset your system or even reinstall Windows.
My main drive is assigned the letter 'C' on my system, and I have quite a few other drives in RAID. Your main drive letter should be substituted for 'C' if it is different, and any other drive letters and paths should be changed to reflect your system. First and foremost, read the file "C:\Windows\INF\setupapi.dev.log" to find the drivers that where last updated. Hopefully, you will have a good idea what driver may be causing the problems. Save this to a USB flash drive to access this on another computer, if that is available. But in any case, save it to something that you can read back from. This file was invaluable in helping to figure out what driver package I needed to remove, and losing access to it would have been a disaster. In my case that driver package was OEM7.INF but yours will almost certainly be different. This file is somewhat cryptic and difficult to read. The entries you are looking for are most likely to be at the bottom. It seems to refer to the entire collection of files that make up a driver as a package. These files include the .INF file as well as the .SYS file or files. For my install, the driver package that was installed was referenced as OEM7.INF, but that is not the folder that holds the drivers files. This seems to be a label for the package, but I could be wrong. I am not an expert when it comes to drivers construction. The folder that holds all of these files seems to be referred to as a repository. I am going to use these terms below when describing the steps I took to recover my system.
Then execute these commands to find out more information and attempt a fix:
1)
prompt> notepad C:\Windows\INF\setupapi.dev.log
This will open notepad with the correct log file to read. This is going to take a little time to figure out, but I promise you the information is in there. Make note of all of the information about the driver or drivers that you believe may be causing problems. You will need this information not only to remove the driver, but to put it back if needed. The package I was looking for was named OEM7.INF once it was installed on my system, but the actual repository that it was saved in was named 'rcbottom.inf_amd64_C3117b26262da451'. This is the type of information that you will need to find in this file.
2)
prompt> C:\Windows\System32\Dism /image:C:\ /Get-DriverInfo /Driver
em7.infThat command will provide you with the information on what that driver package provides, as well as the version number, so that you know you are getting the right driver. Reading all of the data that is supplied by DISM was really helpful in my case. I could see that this package was the new version and that it was 'boot critical'. This gave me more confidence that this was the offending driver package. I don't believe in having too much information.
3)
prompt> C:\Windows\System32\Dism /image:C:\ /Export-Driver /Destination:H:\WinX-NVMe
This command will back up ALL of your third-party driver packages. DO THIS! I don't care if you have to go and buy a USB flash drive...DO THIS! If you don't, you run the very real risk of losing your install. If I hadn't done this, the computer I am typing this on right now most likely would be receiving a fresh install of Windows 10. In the above example, I was saving to a USB flash drive with the drive letter 'H' and a folder named 'WinX-NVMe'. You will have to replace these with the full path to the location where you intend to backup these driver packages. My backup was almost 2GB in size, so make sure to have a fair amount of space for this. But, DISM will tell you if it runs out of space before the backup is completed so don't worry. Look into that folder once you are done with the backup. There should be a bunch of folders with really long names like the repository name that I listed above. They WILL NOT be labelled OEM1.INF, OEM2.INF, etc. That is why you have to read that log file carefully. To make sure that I had found the right repository to match my OEM7.INF package I used DISM to get the driver information and pointed it to the backup data with this command:
prompt> C:\Windows\System32\Dism /image:C:\ /Get-DriverInfo /Driver:H:\WinX-NVMe\rcbottom.inf_amd64_C3117b26262da451\rcbottom.inf
Again, you would replace the drive letter and the path with your USB flash drives letter and path to the backup files for the '/Driver' argument. But DISM printed out the exact same data that it did for the command in step 2 above. That way, I knew I had the correct driver and could put it back if I really needed to, and I did need to. Don't proceed until you have made sure that you have found the repository that contains the package that you are about the remove. You can't undo the next step otherwise.
4)
prompt> C:\Windows\System32\Dism /image:C:\ /Remove-Driver
em7.infThis is the scary moment, but remember, you backed up ALL of your third-party drivers and you should be able to reinstall this if it doesn't work. Find the actual driver directory in the 'setupapi.dev.log' file. As I said, it is long and cryptic, but it DOES tell you where the driver repository is at and what its name is. Mine was: 'rcbottom.inf_amd64_C3117b26262da451' and the .INF file inside that repository was named 'rcbottom.inf'. If you need to reinstall this for some reason, it should reinstall under the OEM*.inf repository that it did initially. Mine reinstalled to OEM7.inf when I needed to reinstall this package due to "PAGE FAULT IN NON PAGED AREA" errors that I received. This page fault error occurred after I uninstalled the OEM7.inf driver package the first time via DISM. But my system did start right up after I removed OEM7.INF. It was only after I restarted my computer that I started to get the page fault error. That is why you must back up those driver repositories. You never know...you just might need them. I did.
5)
prompt> C:\Windows\System32\Dism /image:C:\ /Add-Driver /Driver:H:\WinX-NVMe\rcbottom.inf_amd64_C3117b26262da451\rcbottom.inf
The command above will install the driver back on the system. When I needed to do this it installed back to the OEM7.INF package like it was before I removed it. I can't guarantee that this will be the case for you, but it did work for me. As stated above, you will need to substitute your systems information in the command. I included my command calls to give you a real-world example of what the command will look like.
In closing, I know that there were a lot of commands to issue at the command prompt, with a lot of arguments that have to be passed to DISM to get this to work. I attempted to keep things clear by quoting file and folder names, and using different formatting to call attention to important things. I apologize if it made this difficult to read. Also, I tried to remember all of the commands that I used, but it is possible that I may have made a mistake. I am going off of my memory after all. If something doesn't seem to work the way that I have mentioned, look up the page for the DISM tool and read that. Actually, you should do that anyway. Obviously you can get on the Internet, or you wouldn't be reading this, right? You should remove the driver package that is possibly causing problems only when you are sure that you have your backup done and you know where the driver repository that you are about to remove is located. So that way, you can put it back if need be.
This is dangerous! It can remove files that will force you to reinstall Windows 10 if done improperly. Only do this if you are already considering a fresh install of Windows on your system. It worked for me, but it may not work for you. If you do it wrong, it could cause more harm than good. But I hope that this will help someone fix their system and not require a wiping of Windows with a loss of your data. That sucks. If I have made any mistakes above, please post a correction below so that we can help others fix their system. Well, I have been at this all day and I am done now. Good luck!
Continue reading...