Unable to load kernel driver (not yet supported on this kernel version)

[MarekKnapek]

ISSUE DESCRIPTION HAS BEEN REWRITTEN BY MAINTAINER @jxy-s:

This issue is for requesting support for new Windows kernel versions. The kernel driver will refuse to load on a Windows operating system running a kernel (ntoskrnl.exe) version that it does not recognize. This behavior is by design. The driver relies on specific data that must be updated and published to support new kernel versions. This data includes internal offsets within the operating system, which the driver uses to provide extended capabilities and system inspection. The data is signed using a cryptographic algorithm and verified by the driver before it is loaded. This signing process ensures that the data has been produced by the project maintainers and not by a third party, preventing potential misuse or abuse of the kernel driver.

To request support, please post a screenshot of the error dialog (see example above).

Please note: Support for new kernel versions may be delayed for various reasons. Usually, Microsoft makes the necessary information public within 24 hours of a new kernel version being released. However, on rare occasions, this information may take days or even a week to appear. In some cases, Microsoft may not provide sufficient information, requiring more effort on our part to update the data. Additionally, delays may occur if the maintainers are occupied with other tasks. While we typically respond to new kernel versions within 48 hours of their release, there are times when it may take up to a week. We are working on automating this process to improve our response time.

We appreciate your efforts in requesting support for new kernel versions and ask for your patience while we work through the necessary updates.

[ge0rdi]

I have the same with 10.0.1941.3391 kernel.

I assume it is related to recent dyndata changes and these builds are simply not supported by driver yet. Hopefully the support will be added soon.

[jxy-s]

I have the same with 10.0.19401.3391 kernel.

I only have 10.0.19041.3393 at the moment and there aren't symbols available. @ge0rdi could you send me your ntoskrnl.exe 10.0.19041.3391? Discord, email, or attach it here should be fine.

Windows Server 2022 x64, 21H2, 10.0.20348.1906

I'm adding Windows Server 2022 offsets soon.

[ge0rdi]

could you send me your ntoskrnl.exe 10.0.19041.3391?

E-mail sent.

[jxy-s]

Thanks for getting me the build @ge0rdi - like you mentioned in the email symbols are also not yet published for 3391 yet. Once they are I'll make sure dyndata gets updated.

@MarekKnapek I added dyndata for Server 2022 here: https://github.com/winsiderss/systeminformer/commit/03f5c8c2e3a3d93102b8e4dc691be9ca9b438fbd - it'll get picked up in the next build

[MagicAndre1981]

Microsoft released KB5029331 first as 19041.3391 and 2nd version is 19041.3393 in Release Preview/Insider version which is now also releaded to public in version 3393.

[ge0rdi]

Thank you @MagicAndre1981 . After manual Windows update check I'm on .3393 too.

[MagicAndre1981]

ok, on 1809 LTSC 17763.4737 I also miss the ++ , so no driver is loaded for System Informer version 3.0.7029, but I dont get the messagebox

[MarekKnapek]

Out of curiosity: What is this dyndata thing for? I can see that it is stored into the Registry. It is definitely not a Windows thing, it is SystemInformer thing. Maybe for communication between the user-space part of SI with kernel-space part? But why is it needed? What purpose it serves? What would happen if it was not there? What are alternatives for it? Why is it needed to be Windows version specific? Sorry for bothering you with so many questions.

[jxy-s]

What is this dyndata thing for? ... Maybe for communication between the user-space part of SI with kernel-space part? But why is it needed? What purpose it serves?

They're undocumented offsets used for both protections and APIs from the client: https://github.com/winsiderss/systeminformer/blob/4c28c8f7ba396eab1fbc13960e9731203bd60f5d/KSystemInformer/include/dyndata.h#L31-L75

What would happen if it was not there? What are alternatives for it?

The driver can't function without them. They're required for the protections to function correctly. The old driver would load without them, but it was arguably mostly useless without them. There was some functionality without them, but it was a bit non-obvious why some things would work and some wouldn't. So, during the rewrite we opted to make it a requirement. This come with the benefit that we know where we don't have support/visibility. Obviously the cost is we have to work harder to have more compatibility.

Why is it needed to be Windows version specific?

Because they're undocumented offsets that are version-specific.

[poqdavid]

I hope this helps. I am experiencing the same issue after installing KB5029351. Before this update, I only got that message once when I installed Build 3.0.7029, but now I get it every time I launch System Informer.

[jxy-s]

https://github.com/winsiderss/systeminformer/commit/137cc3a698d5960d68f63b2968a5142e25023f9c adds support for 10.0.19041.3393 and 10.0.22621.2215

Will be in next build 👍

[ge0rdi]

I can confirm that with latest SI driver loads on 19041.3393. Thank you very much.

[MagicAndre1981]

Ok, I disabled the warning dialog in setting, when I activate the dialog, I see this for 17763.4737:

[jxy-s]

@MagicAndre1981 when I was scraping to rebuild the offsets I missed three builds: 10.0.17763.4499 10.0.17763.4644 10.0.17763.4737

I just went over them and the offsets didn't change from 10.0.17763.4377 - I updated dyndata here: https://github.com/winsiderss/systeminformer/commit/f733df42b4f20f9e938303e4231403d0fd29bd95 - will be in next build 👍

[poqdavid]

The same error happened again right after installing update KB5030219, OS build 22621.2283

[jxy-s]

Thanks for letting me to @poqdavid - I'm grabbing the new versions now.

[kotenok2000]

22621.2283 Should i send my ntoskrnl.exe? ntoskrnl.zip

[jxy-s]

Symbols are not yet available for 10.0.22621.2283, I'll keep checking back - when they're available I'll update dyndata 👍

[jxy-s]

https://github.com/winsiderss/systeminformer/commit/d859dad08169721df6c66b5be580d0558fab76dc will be in next build 👍

[MagicAndre1981]

as expected I also get the warning again for 1809:

and 1904x.3448:

[poqdavid]

@jxy-s out of curiosity when you guys update System Informer for newer kernels does it lose its compatibility with older kernels? Cause I have been thinking to switch to RP channel on Windows and I was curious about how this whole thing works

[jxy-s]

you guys update System Informer for newer kernels does it lose its compatibility with older kernels

No, it doesn't break compatibility. We support older kernels. We support release builds for Win10+ x64/ARM64. The supported kernel versions are specified in https://github.com/winsiderss/systeminformer/blob/master/kphlib/kphdyn.xml

RP channel on Windows

We do not yet support preview builds. Updates to those kernels are too frequent for me to keep up with manually. I'm hoping to finish some automation eventually to support them.

[MagicAndre1981]

I noticed I have an older SI Rev.6806 running on another Win10 17763 and here I see the ++ so driver is loaded on 17763.4851 🤔 🤷‍♂️

[jxy-s]

I noticed I have an older SI Rev.6806 running on another Win10 17763 and here I see the ++ so driver is loaded on 17763.4851 🤔 🤷‍♂️

See: https://github.com/winsiderss/systeminformer/issues/1823#issuecomment-1693053377

Dyndata format had to change and I went to rebuild all the offsets using some tooling. I missed a few versions. I've corrected it already, once a new build is out that kernel will be supported.

Older releases supported it with the older format. But there were bugs.

[kotenok2000]

Why process hacker displayed + and systeminformer displays ++?

[MagicAndre1981]

the + and ++ show that both have different driver usage levels while ++ is the best

[MagicAndre1981]

3.0.7148 fixed it on 19045.3448, but NOT for 17763.4851

[jxy-s]

@MagicAndre1981 send me your 10.0.17763.4851

It isn't defined here: https://github.com/winsiderss/systeminformer/blob/9fa8d51956f3b868617c27f4ec761e8b1f26be8f/kphlib/kphdyn.xml#L427-L433

I can't seem to locate that version myself. If you send it to me I can look into adding it.

[MagicAndre1981]

@MagicAndre1981 send me your 10.0.17763.4851 I can't seem to locate that version myself. If you send it to me I can look into adding it.

ntoskrnl.zip

[jxy-s]

Thank you @MagicAndre1981, updated here: https://github.com/winsiderss/systeminformer/commit/e940474fae1300b17bf8e754ed5ade19c9e8f651

[MagicAndre1981]

Thank you @MagicAndre1981, updated here: e940474

I selfcompiled it at rev.1750 and now get this error message:

("specified event is not monitored" - my poor translation)

[JJRousseau]

I'm on 10.0.22621.1928 but it seems to think it's a preview build.

EDIT: Apparently I accidently installed an insider servicing stack a few months ago and this is why. It's also why I haven't received a version update.

[kotenok2000]

Latest prod version is 10.0.22621.2283 Update your system.

[badjawe]

Since windows updates kb5030183 and kb5030180, I have the same issue , "unable to load kernel driver". Back to last restore point before installation, no error message, after re-installation of the kbs,the message back again.
Windows Version 22H2 (build du système d'exploitation 19045.3448). System Informer 3.0.7148 (ed40620)

[jxy-s]

@MagicAndre1981

I selfcompiled it at rev.1750 and now get this error message:

Could you try another build with the latest commits? I improved the error messaging so we can see the actual error code instead of just the localized string. My guess is you built yourself using your own signing keys outlined here. I now recognize that information is incomplete, I'll update it, but I think you may have not rebuilt the dynamic data using your signing keys (.\tools\CustomBuildTool\bin\Release\CustomBuildTool.exe -dyndata). Note that both the dynamic data, kernel driver, and the user mode binaries need rebuilt after you generate and place your developer keys.

@JJRousseau

I'm on 10.0.22621.1928 but it seems to think it's a preview build.

We have seen in the past that preview build and the kernel file version can diverge. My guess is your kernel version is actually 10.0.22621.1928 but the OS reported version is >10.0.22621. See the following, which checks the "OS reported version", that might be different than what we print as the "Kernel version": https://github.com/winsiderss/systeminformer/blob/8d8843eebfef43334c2eef60e91125c9d19a9538/phlib/global.c#L190-L199

I've updated the message box information displayed there to include more information about the environment in which the error occurred, here: https://github.com/winsiderss/systeminformer/commit/8d8843eebfef43334c2eef60e91125c9d19a9538

@badjawe

Since windows updates kb5030183 and kb5030180, I have the same issue

Based on that error message in the window, I think you might be running an older version. I'm also not sure what HKLM\System\CurrentControlSet\Control\WMI\Security\... has to do with this?

[MagicAndre1981]

ok, I haven't done the signing thing. So I'll wait for next official nightly

[poqdavid]

KB5030310, OS build 22621.2361, Kernel 10.0.22621.2361

[jxy-s]

10.0.22621.2361 and 10.0.19041.3516 are both on my radar, waiting for symbols to be published 👍

I'm not seeing a new build for Server 2022 yet.

[jxy-s]

Updated here: https://github.com/winsiderss/systeminformer/commit/d1a6baf440e357f1c1806554ad97df4a5972c3de 👍

[MagicAndre1981]

7251 works now fine in 17763.4851 with full driver support (++ in title)

[MagicAndre1981]

3.0.7254 was not offered via updater, so I extraced the zip and this is the same error I get with my self compiled version:

[jxy-s]

We're working on build pipelines. Two things here:

was not offered via updater

This is intended, deployment is disabled while we're testing.

so I extraced the zip and this is the same error

Signatures files (.sig) aren't in the zip. Use systeminformer-3.0.7254-setup.exe if you want, but probably best to wait until we're done testing. These builds will be pulled shortly.

[MagicAndre1981]

ok, the .sig file is present in both, the zip and exe. I'll revert to the older version.

[jxy-s]

Thanks, I just noticed the issue with the pipeline that is causing the .sig not to be correct. So, that's probably what you're running into. I'm addressing that now. Thanks for your patience. In general tho, just because a build shows up on si-builds doesn't mean it's ready for consumption.

[jxy-s]

Pipeline work is complete - 3.0.7256 should be available for upgrade shortly.

I'm going to leave this issue open for a while longer. But all issues to load should already be resolved.

[MagicAndre1981]

3.0.7256 is offered and works fine.

[badjawe]

System Informer Version: 3.0.7256 (121e1d2) Many thanks for your hardworking. 🙂

[chrcoluk]

So I downloaded 7256 as I have the kernel driver error on 19044,3488

Is it normal to have to reboot to replace ksi.dll? (I did shutdown system informer before trying to update). The dll remains in use with system informer not running.

--

Never mind updated now using the update checker, I guess manually exiting system informer keeps ksi.dll active but using the updater removes it from memory.

[jxy-s]

Is it normal to have to reboot to replace ksi.dll?

Yes, but generally it doesn't update. ksi.dll is a library used by the kernel driver. It can not be unloaded. The purpose of this DLL is to extend the kernel and provide functionality that would otherwise be unsafe or impossible. The updater will check the hash of the DLL to know if it needs replaced, if it does a reboot is requested for the update to finish.

[MagicAndre1981]

And race starts again with new updates: