![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(35.2, 22%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJF%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 18%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETL%3C/text%3E%3C/svg%3E)
Hello @Johannes Fellinger ,
Thank you for providing the initial crash dump details and the additional request payloads.
Looking at the provided stack trace and the extra data, it appears that the issue might be occurring during the completion path of the OID request.
Based on your follow-up, I noticed that the cloned requests processed by brawcap and BPpcap do contain a valid InformationBuffer pointer (0xffffab0c3e0de3d4). However, when the original request propagates back up to pacer.sys, the InformationBuffer unexpectedly becomes 0x0, while the BytesRead field remains set to 0x264.
The trace shows pacer!PcFilterRequestComplete and ndis!ndisPostSetOpenRSSParametersHelper processing the return path, with third-party drivers positioned below pacer.sys in the stack:
-
brawcap!BrcOidRequestCompleteEntryPoint->brawcap!CompleteForwarded -
BPpcap+0x2cee -
ndis!NdisFOidRequestComplete -
pacer!PcFilterRequestComplete
A common scenario in NDIS filter driver development that can lead to this behavior involves how cloned OID requests are handled upon completion. When a filter driver clones an OID request and passes it down the stack, it must ensure that when the request is completed, the resulting data (such as the InformationBuffer and BytesRead) is correctly mapped back to the original OID request before calling NdisFOidRequestComplete.
If an intermediate filter driver preserves the BytesRead value but fails to properly map or provide the InformationBuffer back to the original request, it could result in the upper layers (like NDIS or pacer.sys) attempting to access a null or invalid pointer. This mismatch directly aligns with the KMODE_EXCEPTION_NOT_HANDLED (1e) bugcheck you observed.
To help isolate the issue, I suggest the following steps:
- If you are an administrator/user: I recommend temporarily disabling or uninstalling the applications associated with the
brawcap.sysandBPpcap.sysfilter drivers (often related to packet capture software like npcap/winpcap). This could help verify if these drivers are contributing to the instability during boot. - If you are developing the third-party filter drivers: I suggest reviewing the logic inside the OID completion handlers (e.g.,
CompleteForwarded). Specifically, verify that forOID_GEN_RECEIVE_SCALE_PARAMETERS, the originalNDIS_OID_REQUESTstructure is correctly updated and that the buffer pointers are valid before passing the request up the stack.
For further reference on handling OID requests within filter drivers, you might find these resources useful:
I hope this information assists you in debugging the issue. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.
Thank you.