Recently I’m working on upgrading our product to be compatible with Windows 10, found that one of my driver will cause BSOD CRITICAL_STRUCTURE_CORRUPTION, means PatchGuard violation on Win10 x64, but this driver used to works well on any other x64 platforms. For some reason, my driver needs to map a DLL module into some target processes, and currently this module is mapped to every process after the process created. I don’t think doing this could be called Kernel Patch behavior cause of everything occurs on user space, not kernel space. To understanding the actual rule of PatchGuard, we can’t just wait for the new offical document from MSFT, lot of time was wasted to locate this problem! I would be very grateful if anyone can share any experience or information about PatchGuard on Win10.
what is the type of the corrupted region in your case ? i mean https://msdn.microsoft.com/en-us/library/windows/hardware/ff557228(v=vs.85).aspx?f=255&MSPPError=-2147217396
Why do you think Microsoft should allow you do that?
Seriously? That doesn’t sound like malware behavior to you?
Peter
OSR
@OSRDrivers
Well, let’s wait until Mr.Burn reads the above statement…
I guess he is going to react to it more or less the following way
Anton Bassov
Maybe you all misunderstanding me. One of my requirement is hook Windows Audio Service to make my virtual audio device work well on remote session, this thing can only be done in user space. There is another way to provide an Audio Endpoint DLL but it leaks document so we can’t choose it. I just want to know why PatchGuard alarms for this behavior, even it is not a kernel hook or kernel patch. I’m NOT doing any dirty thing.
Thanks, the region type value is 0x1F, none of listed types, that’s why I said we need a new official document for this.
i also inject my dll from driver in win10 x64 to some processes on start (explorer and sppsvc (protected process !) ) however in my case all work, without any problems. faster of all problem in method of dll injecting or how dll work. if say - only inject dll, but dll will be nothing doing - only live in memory - also will be crash ?
Yes, mapping DLL section by ZwMapViewOfSection into all processes can simply trigger this BSOD after several hours, without doing any injection. It seems I should rewrite the implementation of this stuff in order to not affect something that I can’t touch.
“mapping DLL section by ZwMapViewOfSection into all processes” vs " map a DLL module into some target processes" - big different. not think that map into all processes good idea. and if say dll used kernel32, csrss subsystem, in princip will be not worked say in smss.exe . i be try inject only in really some target processes. than mapping DLL section by ZwMapViewOfSection very not equal to LoadLibrary(LdrLoadDll) functional. so you need do something more than ZwMapViewOfSection. how/when dll got control, live in process as “normal” dll or faster like shell code ?. if i research this - i be try off all functional of dll - are still crash ? inject only to explorer or/and to some protected process (say audiodg.exe interesting for you, how i understand) - look are will be crash in this case too? may be you crash some system|protected process and than as secondary result CRITICAL_STRUCTURE_CORRUPTION ? for example when working in protected process - exist some specific. say simply ZwCreateSection on usual file can return status STATUS_INVALID_IMAGE_HASH. if this in initialization process phase - all process can exit with STATUS_DLL_INIT_FAILED. so here exist area for research. however i shure that possible inject dll from driver in windows 10 x64 in some processes( protected included) too. of course if without errors
Thanks for question these points, as my previous post of this thread, my driver works well on other x64 platforms like Win7 and Server 2012R2, etc. This DLL module will only link to ntdll.dll and my driver will handle initialization works like calculating module hash or setting import table when it gets loaded. It’s obviously not a good idea I see. Later I’ll try the way you have mentioned and post the result here.
“This DLL module will only link to ntdll.dll” - in this case normal load it to any process.
“and my driver will handle initialization works” - i have done differently. inject shell code to process, with apc, which than call LdrLoadDll. so actually standard ntdll loader do all stuff
Advance J wrote:
Thanks, the region type value is 0x1F, none of listed types,
that’s why I said we need a new official document for this.
CRITICAL_STRUCTURE_CORRUPTION (109) with type 0x1f is a
“Modification of a protected process”.
See output of the ‘analyze -show 0x109’ command in the latest WinDBG.
yes. really. for test debug protected process (sppsvc.exe). while i set breakpoint on ntdll/kernel32/rpcrt4 - all work normal. after setting breakpoint on sppsvc.exe code direct - found call to RaiseFailFastException(c0000602) and just before this call sppsvc zero all stack, for make harder found place from where this called ( http://imageshack.com/a/img540/9493/9aH6D1.png ). however bsod i not catch 
> Maybe you all misunderstanding me. One of my requirement is hook Windows Audio Service
Oh my God, you’re just near to commit a criminal offence under US laws 
Once more: developing copyright-protection “cracks” is a crime in the US. Google for “DMCA”.
space. There is another way to provide an Audio Endpoint DLL but it leaks document so we can’t
choose it.
Yes this is the way of choice, even though it will require some reverse-engineering to fill the documentation gaps.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Yes, I learned much in this thread. Already replaced to a better way to achieve same performance and works properly now.