Windows 11 issues.

[T-Troll]

I'm use modified KDU for load unsigned kernel driver for my project.

Recently, i got complaints from W11 users - driver loading fail, followed by BSOD with KMODE_EXCEPTION_NOT_HANDLED - seems like provided by system antivirus.

Can you, please, check what do they change?

[hfiref0x]

#18 (comment)

I'm not goint to debug your own software to figure out what is happening. If you have minidumps and steps to reproduce this -> feel free to attach them here.

[T-Troll]

The same happened with KDU itself, we check it.
Ok, i'll ask for dumps for you and share here.

[T-Troll]

1. In Windows 11, old-style device names doesn't work anymore.
2. BSOD was initiated by service.exe then trying to remove node from namespace, which was loaded by you loader.

So it's not your fault, but good to know, i think.

[hfiref0x]

In Windows 11, old-style device names doesn't work anymore.
BSOD was initiated by service.exe then trying to remove node from namespace, which was loaded by you loader.

This "issue" is entirely your own fault and have nothing to do with what you write. Services.exe is a user mode APP that is responsible for SCM. This loader does not use SCM to map drivers in the kernel space. SCM cannot "remove" anything from kernel because mapped drivers:

1, Does not have "UNLOAD" procedure set (unless you compiled them wrong)
2. Does not managed by SCM in any way

Windows 11 is a marketing relabeling of the same Windows 10, if there is a change like you describe - everything will not work on it.

Suprise, surprise, all the devices names are the same as on Windows 10, Windows 8, Windows 7 and even Windows 2k/NT4.0.

On future note:
there is nothing "incompatible" with kernel in general in KDU loader, because it's just a loader not rootkit or whatever you are trying to load. So it cannot BSOD by design, unlike some script-kiddie software that mess with internal Windows structures to "hide" loaded stuff (rofl).

What can cause BSOD here:

1. Error in shellcode, but then it will also BSOD on previous versions of Windows, which eventually will be reported before;
2. Some dramatic change in Windows kernel that causing incompatibility - obviously not this time;
3. Vulnerable driver it uses to map memory, it is possible, but also clearly not my fault;
4. The thing you are trying to load - your payload <- which is this issue and source of problem in 99.99% cases.

If there is the next time will be another issue with no actual minidumps attached and another portion of BS like in your last post - I will automatically lock this issue without further notice.