> Microsoft's documentation on this is not as good as it could be When I wanted to learn and understand this stuff back in the NT days, I went straight to the Custer(Russinovich)(Solomon book). I have quite a stack of them now.
The knowledge within is not available anywhere else in such a concise fashion....if you can call a 1500pg tome concise that is. Still priceless IMO. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ben Scott Sent: Thursday, August 28, 2014 9:24 AM To: [email protected] Subject: [spam] [dkim-failure] Re: [NTSysADM] move hdd with windows 7 on it On Thu, Aug 28, 2014 at 9:14 AM, Steven M. Caesare <[email protected]> wrote: > While the shotgun approach of nuking _EVERY_ driver in the system > might solve the _SPECIFIC_ issue of this being a boot device access issue ... Since this has come up twice now... What you see in "Device Manager" are not drivers. They're objects in the PNP manager's device enumeration list. Removing objects from Dev Mgr does not remove the driver. The actual device drivers are considered "Services" internally, and are mostly managed by the same Service Control Manager that manages the "regular" services one sees in the "Services" control panel/MMC. Said drivers (and other services) are enumerated in the registry under <HKLM\System\Current Control Set\Services>. Not all of these drivers appear in Device Manager, even when they're running. Drivers set to boot start will always be loaded, regardless of whether a device node exists in the PNP tree (because the drivers are loaded before the PNP manager is available, by the NT loader). I believe it's the PNP manager that normally decides to set a driver to boot start, although I don't fully understand the mechanism. I don't know what rules the PNP manager has (if any) for setting boot start drivers back to system/demand. The main reason to manually remove a PNP device node to fix a boot problem after a system move would be to disable a device driver that's causing problems with hardware on the new system. For example, the driver may be trying to load or probe the wrong hardware, causing said hardware to get confused. Or maybe the driver is getting confused and crashing/corrupting the running system. And it's certainly the case that none of this has anything to do with the HAL, which is it's own beast. If someone still doesn't believe this, go look under the "Services" regkey. You won't find the HAL there. Microsoft's documentation on this is not as good as it could be (it's scattered about, and some things are very under-documented), but here are some starting points: "QUERY_SERVICE_CONFIG structure" https://urldefense.proofpoint.com/v1/url?u=http://msdn.microsoft.com/en-us/library/windows/desktop/ms684950.aspx&k=4%2BViHuL0UtSJBpVrYi3EdQ%3D%3D%0A&r=Jek3QSvahmIrNAN1nuPfQA%3D%3D%0A&m=hvGX7wHMlmAe9GzOFx7hSyb1cZjfhGSCXVXvizGQyX8%3D%0A&s=3bf7f4654c620427ba570aa8ef71f101bb45f9432192371479131adf976d7df0 "Specifying Driver Load Order" https://urldefense.proofpoint.com/v1/url?u=http://msdn.microsoft.com/en-us/library/windows/hardware/ff552319.aspx&k=4%2BViHuL0UtSJBpVrYi3EdQ%3D%3D%0A&r=Jek3QSvahmIrNAN1nuPfQA%3D%3D%0A&m=hvGX7wHMlmAe9GzOFx7hSyb1cZjfhGSCXVXvizGQyX8%3D%0A&s=453f3fe523c7ef8a73edd553f9ae378bf87e73eec580d307a99a00247781a2dd "Windows Kernel-Mode HAL Library" https://urldefense.proofpoint.com/v1/url?u=http://msdn.microsoft.com/en-us/library/windows/hardware/ff565727.aspx&k=4%2BViHuL0UtSJBpVrYi3EdQ%3D%3D%0A&r=Jek3QSvahmIrNAN1nuPfQA%3D%3D%0A&m=hvGX7wHMlmAe9GzOFx7hSyb1cZjfhGSCXVXvizGQyX8%3D%0A&s=961c2e755c766f6a2b6462b318dd5492c2a9274959793f034206891d2698c2d2 -- Ben PG&E is committed to protecting our customers' privacy. To learn more, please visit http://www.pge.com/about/company/privacy/customer/
