Having troubles after update Windows 11 yesterday

@ Martin

This is interesting. I have extracted the HWiNFO64A_171.sys by running HWiNFO64 on another system. Then I have written my own software to load the driver into Windows 11 build 25145, the software simply loads the driver and starts the service, nothing else:



View attachment 7897

Now that driver is loaded, I can start HWiNFO64 again, with all HVCI protection enabled. :D I guess HWiNFO checks if driver is already loaded before it actually tries to load one itself.

View attachment 7898

I don't know if that matter or not, but I named this service 'HWiNFO64 Kernel Driver'.

Wow, that's very interesting! That would mean you somehow circumvented the blocking rules by MS.

Unfortunately we still don't know what exact rules work in build 25145. There's a file
c:\Windows\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml
which defines the rules for blocking various drivers, but it's really odd that it doesn't list HWiNFO and the CPU-Z driver it blocks is rather old. So there must be some other rules enforced that we haven't figured out yet.

I tried to install build 25145 to have a deeper look but for some reason I can't get HVCI to work there, while this was not an issue on the same system with build 22000. So my testing capabilities are currently very limited.

Can you try to install the driver with all other details same as HWiNFO does, i.e. the exact service name, description, path, etc. to see if that will block it then?
 
Last edited:
Might also be interesting to try to load/unload the driver like you did multiple times. Apparently if one renames the driver it works only first time, then next attempt will be banned..
 
@ Martin

This is interesting. I have extracted the HWiNFO64A_171.sys by running HWiNFO64 on another system. Then I have written my own software to load the driver into Windows 11 build 25145, the software simply loads the driver and starts the service, nothing else:



View attachment 7897

Now that driver is loaded, I can start HWiNFO64 again, with all HVCI protection enabled. :D I guess HWiNFO checks if driver is already loaded before it actually tries to load one itself.

View attachment 7898

I don't know if that matter or not, but I named this service 'HWiNFO64 Kernel Driver'.

UPDATE:

Yup, it does matter. If I name the service "HWiNFO Kernel Driver (v171)", it will fail to load:

I guess this only highlights that the driver is in serious need of repair, if you are able to modify and sign code that is not from the vendor to bypass HVCI protection then it just exposes another hole that Microsoft will need to plug
 
Might also be interesting to try to load/unload the driver like you did multiple times. Apparently if one renames the driver it works only first time, then next attempt will be banned..
I have tried this. I will try reinstalling the latest IP ISO on a clean drive and try again. I just want to thank you for your work on this tool I have been using it for like 10 years or more.

However one suggestion, perhaps you could split 'beta' and 'alpha' updates, because I like to use beta, but I feel the update frequency is very high, almost every time I login to windows I am prompted to update it. Perhaps an alpha channel with bleeding-edge nightly builds would be better for that and beta just before pre-release. Anyway sorry to go out of scope of topic just wanted to say my opinion on that.
Thanks again.
 
Update:

Yup, it does matter. If I name the service "HWiNFO Kernel Driver (v171)", it will fail to load:

\??\C:\Users\hundr\Downloads\HWiNFO64A_171.SYS failed to load

The HWiNFO Kernel Driver (v171) service failed to start due to the following error:
The parameter is incorrect.
The HWiNFO Kernel Driver (v172) service failed to start due to the following error:
The parameter is incorrect.

Reminds me of Visual Studio toolsets. :-D

Update:

I tested as you proposed Martin, to try loading it multiple times with different names, and indeed it's being blocked on next attempts, regardless of driver or service name, or even the executable that starts the service. Interesting that it worked first time. :-O
 
Last edited:
Thanks for your feedback guys, that's very valuable!
Look like MS is doing some semi-intelligent checks. My theory is that the first time it allows a "new" driver to load if it's not in the local ban list and meanwhile does online submit data about it, which it turn gets a response from MS servers with a new ban. To prove this, it might be interesting to disconnect the machine from Internet, install the driver with a new service name that's not banned yet and then try again and again :) If all subsequent runs will work, it means the blocking policy is determined and updated online.
 
LOL. This is so weird. I've spent last couple of hours extending my tiny application for managing driver services, so when it was time to test it:

hw05.png

Then I tried to stop it and then start again, the issue returned:

Service stopped: HWiNFO Kernel Driver (v171)
Failed to start service: The parameter is incorrect

All this crap seems to be about specific period of time. I didn't restart my PC since last failure, neither cleaned up any cache or Defender temporary files. Weird as f*uck. :)

PS: If you need this app, let me know.
 
Thanks :) BTW, you should be able to manage drivers also using the "sc" command ;)
Yeah, I did that yesterday. But you know how programmers are, need to make their own crap :-D Plus I never had experience of coding for services using Win32 API yet, good to get knowing it.
 
Alright, final workaround:

hw07.png

1. Make sure all old services are deleted
2. Make sure all physical driver files are deleted, not renamed, because Windows keeps track of the file regardless of file name
3. Extract driver file to any location (can be the same as last time)
4. Create new service using chosen driver location
5. Start new service
6. Start HWiNFO (from here on you can use it how long you need, you can even restart it, it will work until you stop the service, either manually or with a reboot)
7. Once you have stopped the service for any reason, repeat the above steps 1-6

Martin, you need to share HWiNFO64A_171.SYS file + 32-bit, ZIP or anything would do, atleast until this is resolved another way. You can edit this post and insert a link if you like. Damn, just noticed that HWiNFO comes in different editions, some of them are not free. Well, share the free one? Dunno.

For those who are not aware how to manage services on Windows, my app mentioned above, is available from here: https://te-home.net/?do=work&id=misc&file=276

:cool:
 
Last edited:
Actually, that's what HWiNFO does when the "Persistent Driver" option is enabled - it keeps the driver installed even after closing HWiNFO and if you click Remove, it removes the driver and deletes the file.
 
Actually, that's what HWiNFO does when the "Persistent Driver" option is enabled - it keeps the driver installed even after closing HWiNFO and if you click Remove, it removes the driver and deletes the file.
Yes, I can see that. But in order to do so you need to run the application, and in order to run the application, you need the driver being loaded. :D

Where does HWiNFO put the driver when persistent is enabled? I will try something.
 
The initial welcome dialog of HWiNFO doesn't require the driver to be installed. That gives you a chance to reach the main settings options including Driver Management.
The driver is loaded only when the system scan starts.
With "Persistent Driver" option enabled the driver is by default stored in: c:\windows\system32\drivers
 
Alright, so I removed all services and drivers, also HWiNFO64.INI. Started up HWiNFO64, went directly to settings, checked persistent driver and tried installing manually, without success.

we01.png

So I copied the driver manually to the System32\drivers and created service using my app, then started the service. I still see "Not installed" in HWiNFO64, even after restart. What am I missing? Is persistent driver named different from "HWiNFO Kernel Driver (v171)". Is the driver file name different from "HWiNFO64A_171.SYS"?

hw08.png

Or is there even a hidden setting that states "driver is now installed in location a\b\c with name abc"?
 
Last edited:
Nothing special. You might verify your service's settings against those made by HWiNFO if you check registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_171
 
Nothing special. You might verify your service's settings against those made by HWiNFO if you check registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HWiNFO_171
Thats why I wrote following above:
Is persistent driver named different from "HWiNFO Kernel Driver (v171)". Is the driver file name different from "HWiNFO64A_171.SYS"?
* So HWiNFO creates a service named "HWiNFO_171" in persistent mode?
* Where did we get "HWiNFO Kernel Driver (v171)" from then?
* Does HWiNFO set different service name and display name?

Edit:

I figured out myself. Service name must be "HWiNFO_171" in order to show "Installed" in settings. Ok, this one is good, now, what is the default start type for persistent driver (boot, system, auto, demand)? I will try with different settings and see if it autoloads using one of those.
 
Last edited:
Yes, you figured that out already.
With "Persistent Driver" option enabled, the service start type is System-start, without that it's Demand-start.
 
Alright, tested all possibilities, nothing works. Windows seems to not load the driver on start no matter what. Only my solution above works if one wants to use HWiNFO meanwhile system is up and running, after that need to delete physical file and recreate service.

I also noticed that HWiNFO tries to load existing service, if it does not success, it removes the service. So only manual setup works here too.

I guess we have to wait for next thursday, MS rolls out new build on beta channel that day every week. Will continue testing then. :)
 
Alright, tested all possibilities, nothing works. Windows seems to not load the driver on start no matter what. Only my solution above works if one wants to use HWiNFO meanwhile system is up and running, after that need to delete physical file and recreate service.

I also noticed that HWiNFO tries to load existing service, if it does not success, it removes the service. So only manual setup works here too.

I guess we have to wait for next thursday, MS rolls out new build on beta channel that day every week. Will continue testing then. :)
Nice debugging thanks.
 
Back
Top