We write a windows AHCI driver that replaces the normal in the box msahci.sys driver. The boot system is installed on another controller, either SAS or SATA, but we do not boot using our AHCI driver. Our problem is that during the course of running diagnostics we may need to remove our AHCI driver and replace it with the in the box msahci.sys file. I have a modified devcon program that is used to uninstall our package. It physically removes our AHCI driver file, the registry entries associated with it, the INF/PNF files, and drills down in to the cache areas and removes any cached files as well. The system is then booted. Once our modified devcon has been run, the system supposedly is in a pristine condition.
However, and ain't there always one of those, we find that after restarting the system and allowing msahci.sys to be restored from system cache, accessing the drives connected to the msahci controller is problematic. I may or may not be able to do an IDENTIFY, and reading an LBA will always return an error. In working on the problem I have found that if after the uninstall boot, I then use Device Manager to uninstall the Standard AHCI 1.0 Serial ATA Controller then boot once again, that now we have full access to the drives connected to that controller. Simply stated here is what I have:
1. Install our win AHCI driver.
3. Run diagnostics on drives connected to win AHCI controller.
4. Uninstall win AHCI using modified devcon.
6. Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
8. Run diagnostics on SATA drives using the MS AHCI driver.
What we would like to do is remove steps 6 and 7. Does anyone know a reason why we have to use Device Manager to uninstall the inbox drivers and then reboot when the reboot in step 5 should have re-instated the inbox drivers? Can this be done through another modification to our devcon? I can provide a code snippet if it would help.
H (952) 223-1349
C (952) 454-4629