7 ms·
>...because it’s the hardware management service and if it goes down you’re no longer managing the hardware? I’m no expert on device drivers but to my knowledg
by codeinstyle 7y ago
>...because it’s the hardware management service and if it goes down you’re no longer managing the hardware?
I’m no expert on device drivers but to my knowledge, Windows already allows you to manage devices and install drivers through Device Managers.
Then if drivers are already installed for the various devices and hardware components, what exactly is the hardware management service managing on top of the individual drivers?
I am asking this as the only plausible reason to be doing this (at least for me) is if Windows isn’t providing enough tools for device management that needs coordination between the hardware components on the machine, so I would appreciate someone with more knowledge to shed some light on the subject.
- monocasa 7y agoDevice Manager only handles kernel drivers. Best practice is to put as much as possible into a highly privileged, but still user mode process so it can crash without bluescreening your system. If you assume that this code can crash (hence why it was delegated to user mode in the first place) it makes sense to code in a resurrection capability.
- zaphirplane 7y agoWindows services have a restart if I crash mode, why wouldn’t that be used instead. This seems about making sure the user can’t stop it from starting
- monocasa 7y agoIt's a huge pain on the ass to setup right. Soft faults where the process is still running but is deadlocked don't get restarted for instance.
- zaphirplane 7y agoSame problem if you write your own supervisor except you are writing a process supervisor
- monocasa 7y agoWell, no, because you can write your supervisor in a way that does protect against that. In fact that's hat they're doing here.