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:
- Install our win AHCI driver.
- reboot.
- Run diagnostics on drives connected to win AHCI controller.
- Uninstall win AHCI using modified devcon.
- Reboot.
- Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
- Reboot
- 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.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
> 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
Are you using standard documented APIs for this or groveling the filesystem yourself and deleting files?
d
debt from my phone
From: Gary Little
Sent: 3/5/2012 6:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MSAHCI install problem
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:
- Install our win AHCI driver.
- reboot.
- Run diagnostics on drives connected to win AHCI controller.
- Uninstall win AHCI using modified devcon.
- Reboot.
- Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
- Reboot
- 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.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.netmailto:xxxxx
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>
The modified devcon uses standard API calls. To be precise, and in order:
- SetupDiDeleteDevRegKey
- SetupUninstallOEMInf
- DeleteFile (primary SYS file in SYSTEMROOT)
- RegDelKey (executed in a loop for all subkeys
Note that there is logic between each step to open and close the required handles, enumerate keys and perform various house keeping tasks.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 5, 2012, at 9:22 AM, Doron Holan wrote:
> 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
Are you using standard documented APIs for this or groveling the filesystem yourself and deleting files?
d
debt from my phone
From: Gary Little
Sent: 3/5/2012 6:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MSAHCI install problem
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:
- Install our win AHCI driver.
- reboot.
- Run diagnostics on drives connected to win AHCI controller.
- Uninstall win AHCI using modified devcon.
- Reboot.
- Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
- Reboot
- 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.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Your reg keys or the system reg keys. You should use a restore point to get back to pristine state. Touching anything on your own that the driver package installs, ir that pnp does to process the package outs you in an unsupported state (including deletion of the sys file)
d
debt from my phone
From: Gary Little
Sent: 3/5/2012 7:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MSAHCI install problem
The modified devcon uses standard API calls. To be precise, and in order:
- SetupDiDeleteDevRegKey
- SetupUninstallOEMInf
- DeleteFile (primary SYS file in SYSTEMROOT)
- RegDelKey (executed in a loop for all subkeys
Note that there is logic between each step to open and close the required handles, enumerate keys and perform various house keeping tasks.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.netmailto:xxxxx
On Mar 5, 2012, at 9:22 AM, Doron Holan wrote:
> 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
Are you using standard documented APIs for this or groveling the filesystem yourself and deleting files?
d
debt from my phone
________________________________
From: Gary Little
Sent: 3/5/2012 6:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MSAHCI install problem
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.
2. reboot.
3. Run diagnostics on drives connected to win AHCI controller.
4. Uninstall win AHCI using modified devcon.
5. Reboot.
6. Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
7. Reboot
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.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.netmailto:xxxxx
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
Doron,
I pass DICS_FLAG_CONFIGSPECIFIC and DIREG_BOTH to SetupDiDeleteRegKey. In RegDelKey I pass the HKLM:\SYSTEM\CurrentControlset\services path and specify our key and sub keys in a loop. This has to support XP so I cannot use the nifty Win 7 registry function that removes key and sub keys in one call.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 5, 2012, at 9:51 AM, Doron Holan wrote:
Your reg keys or the system reg keys. You should use a restore point to get back to pristine state. Touching anything on your own that the driver package installs, ir that pnp does to process the package outs you in an unsupported state (including deletion of the sys file)
d
debt from my phone
From: Gary Little
Sent: 3/5/2012 7:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MSAHCI install problem
The modified devcon uses standard API calls. To be precise, and in order:
- SetupDiDeleteDevRegKey
- SetupUninstallOEMInf
- DeleteFile (primary SYS file in SYSTEMROOT)
- RegDelKey (executed in a loop for all subkeys
Note that there is logic between each step to open and close the required handles, enumerate keys and perform various house keeping tasks.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 5, 2012, at 9:22 AM, Doron Holan wrote:
> > 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
>
> Are you using standard documented APIs for this or groveling the filesystem yourself and deleting files?
>
> d
>
> debt from my phone
> From: Gary Little
> Sent: 3/5/2012 6:59 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] MSAHCI install problem
>
> 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.
> 2. reboot.
> 3. Run diagnostics on drives connected to win AHCI controller.
> 4. Uninstall win AHCI using modified devcon.
> 5. Reboot.
> 6. Use Device Manager to uninstall Standard AHCI 1.0 Serial Controller.
> 7. Reboot
> 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.
>
> Gary Little
> H (952) 223-1349
> C (952) 454-4629
> xxxxx@comcast.net
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hmmmm… you’re sure the problem is the DRIVER installation and not that state in which you’re leaving the controller or drive hardware?
Got a drive analyzer trace?
Peter
OSR
Peter,
Good point. No, I don’t have a trace and cannot get one until Wednesday, but it’s something I need to do. I typically use Powershell to do Restart-Computer or Stop-Computyer after running our modified Devcon to do the uninstall. My first thought is that it is the driver installation since uninstalling msahci and then allowing the system to restore it during a reboot works. My first suspect is my modified Devcon that does the uninstall. There may be something I’m not, or should be doing. It may also be possible that this simply cannot be completely achieved using a software solution and will result in a forced System Restore. I’m already exploring that.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 5, 2012, at 3:31 PM, xxxxx@osr.com wrote:
Hmmmm… you’re sure the problem is the DRIVER installation and not that state in which you’re leaving the controller or drive hardware?
Got a drive analyzer trace?
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer