I’m trying to debug Win10 system that after few hours produces Bug Check 0x109 with following parameters:
Arg1: a39fece391ae85fb, Reserved
Arg2: b3b6f969e42f377d, Reserved
Arg3: 0000000000000002, Failure type dependent information
Arg4: 0000000000000018, Type of corrupted region
In my understanding Arg4 = 0x18 means “Kernel notification callout modification”
Question 1: Do anybody know what means Arg3 = 2 for such situation?
Question 2: Do anybody can recommend debugging Technic for such situation?
In my understanding PatchGuard is disabled as soon as I’m connecting WinDbg. Is there any better approach as disable parts of driver code and try?
System run no any third party antivirus. There is 2 custom drivers that visibly causing the problem.
Both drivers are doing nothing because target hardware is not connected at present moment.
Driver Verifier doesn’t complain about them. However, Driver verifier test was made with WinDbg connected - i.e. with disabled PatchGuard.
Because hardware, if present, may participate in Boot procedure.
Alex, I appreciate your help, but my question is really not a discussion about the software design.
This thread is about possible methods of Bug Check 0x109 debugging.
What’s the repro? The box just stands idle a few hours and crashes? Do you know that Windows 8+ will make drivers permanently non-boot start if no device is enumerated on boot?
Check if the driver was ever loaded into the crashed session. It may be in the unloaded module list. Boot with verbose mode enabled.
What does the driver do in DriverEntry and DriverUnload? Review their code and see if they possibly overrun any allocated memory.
Does the SUT use Intel on-chip graphics? Do you have display low power timeout enabled?
Speaking for myself, I am hesitant to help too much with ANY patch-guard related bugchecks. Especially when provided with so little background information, in a thread started by a relatively unknown OP.
Sorry if that seems uncharitable, but that’s why *I’m* not looking this up for you. What we post here online lives forever, and I have exactly zero interest in helping black hat hackers and malware authors who at some future date might Google-up a detailed explanation posted here . For clarity, I’m *assuming* you are neither of these bad things. Though, the lack of problem detail you’ve provided, and the anonymity of your email address, does nothing to reinforce me in this belief.
Maybe one of the other MVPs or one of the Softies will look up the bug check for you and tell you what the parameters mean.
> I have exactly zero interest in helping black hat hackers and malware authors who
> at some future date might Google-up a detailed explanation posted here
I well understand your reasons.
No, I’m neither hacker nor malware author. If you have an experience with debugging of patchguard issues, may be we can switch offline - I will provide you with all details of the product.
I’m very grateful for your suggestion. Please be sure that “f… with OS tables” will be the very last choice in my most perverse phantasm. Remark that such kind of expressions and such level of discussion don’t fit in my image of the Engineer (sic!).
For people who still interested in technical side of the problem.
We found reason of the fault. Our drivers were not responsible for the Bug 0x109. Simply, the presence of our drivers changed behavior of other components.
Apparently in Windows 10 Bug Check 0x109 is now generated not only by Kernel PatchGuard, but also by Device Guard mechanisms.
I assumes, that many of you may encounter the similar situation in very near future and lack of relevant information in WinDbg will result in very long debugging time as it was in my case.
I’m sorry that discussion on important technical (in my opinion) question turns this way.
With respect, Mr. Metek, you should expect no different given (as I said before) the stunning lack of information you deigned to provide, your lack of an established reputation here, and the fact that you’re posting from an anonymous email address.
For all anybody here knows, you’re a teenager in your parent’s basement cooking up a scheme to take over the world. Your defensiveness in telling us what the fuck you’re doing does little to dispel this.
You can’t blame folks here for being skeptical… Never once did you write “my driver is modifying no OS data,and it is not trying to do anything other than manage its hardware in an architecturally proper way. It is not trying to bypass or defeat patch guard.” You said you’re not authoring malware… OK, but not the same as what I just wrote.
Believe me that I have a good reason to keep anonymous email address in this case. When you are working for some customers you are limited by your contract.
I asked you to contact me via e-mail - if you would do it, you likely would quickly figure out that we even know each other.
Sorry, my fault, I should start this thread with declaration: OUR DRIVERS ARE DOING ONLY LEGITIMATE WORK WITH ITS HARDWARE; THEY ARE DESIGNED IN ARCHITECTURALLY PROPER WAY AND IN NO PLACE MODIFY ANY WINDOWS CODE OR STRUCTURE. IT IS NOT TRYING TO BYPASS OR DEFEAT PATCH GUARD BY ANY METHOD.
In any case, as I wrote previously, we found the problem and it was not ours. So, let me now return to my parent’s basement.
I am glad you resolved your problem. However, your post contains some inaccurate statements that my mislead others into thinking they too understand/have a solution for similar problems.
Merely attaching WinDBG does not disable PG. The mechanisms are trickier than this. Obviously I will not describe them. The short story is that depending on how and when WinDBG was attached, PG may remain active.
Device Guard itself is not related to PG, or PG bug checks. There are protection mechanisms built in the various components which support Device Guard, but they result in a different bug check code when their verifications are violated.
Additionally, Device Guard is typically only active on systems with Secure Boot. On systems with Secure Boot, debugging is not permitted. Therefore, you are either booting with a strange policy that allows debugging on SecureBoot devices, in violation of the standard, or you are booting with Device Guard and UEFI disabled, a strange non-default and meaningless combination, or your issue was actually not related to Device Guard.