BSOD wdf01000.sys bugcheck 0x0000003b

[phagosaurus]

Thought the issue resolved itself but it crashed again. It happened when I picked up a skype call.

 

[cluberti]

Your minidumps are all over the place, but the ones that actually have data (before they crash the debugger.................) claim the faulting module is uxpatch.sys. I wouldn't be surprised if a UX hacking module crashes processes when you are using applications like Skype that are accelerated.

As to the one in question, you're probably going to need to capture kernel dumps, not minidumps. I would also request that you remove uxpatch and then reproduce the issue, otherwise we won't even be able to open the dump files (and it could be the culprit as well, for what it's worth).

 

[phagosaurus]

I already uninstalled uxpatch as instructed earlier. I installed that like 2 years ago and it has never caused an issue.

 

[cluberti]

You've got dumps in here still showing it loaded (and crashing the system). I would say that your uninstall was.... unsuccessful.

 

[phagosaurus]

I'm not sure how else to remove uxpatcher since there isn't an option in the uninstall programs list anymore. I'll try switching to a kernel dump for the next time it happens and upload that though.

 

[cluberti]

The easiest way is likely to boot in safe mode and rename the uxpatch.sys file to something else. Reboot normally, and validate it's still renamed (it might cause an error in the event log about loading it, but it should keep it from loading).

 

[phagosaurus]

Well, I looked in my drivers folder and there isn't a uxpatch.sys so I assume that it is no longer installed.

 

[cluberti]

It's in there somewhere, or it couldn't be loaded in the dump files. Unfortunately, I can't keep windbg open against your dump files long enough to find where it's loaded from.

 

[phagosaurus]

May I ask, which dumps are you looking at? The two most recent dumps should be after I've uninstalled the patcher. The older ones may show that I had it installed. Also, here is an older kernel dump. Not sure if it helps, but it might. https://www.dropbox.com/s/lywt4sfkrm1onva/MEMORY.zip?dl=0

 

[cluberti]

Those were the ones I looked at... I'm downloading the kernel dump at the moment. I'll edit this once I take a look.

EDIT: that dump is also corrupt. Interesting - there's never any stack data, and only claims about "unidentified module" in initial analysis. I can't look at processes or threads, yet the dump is of significant size. Let me clean out my symbol cache and try again, making sure it's not something stuck in cache causing the behavior.

EDIT2: OK, so that solved some things - however, in both of the last two dumps, something in user mode is likely triggering failure (in the first case, there's an I/O request that causes an NTFS write that fails, but I can't see the IRP because it's a minidump - in the second case, something is passing a request that causes a request for an invalid handle, but again, no kernel-mode data because it's a minidump).

2: kd> .exr 0xfffff8800cb5f708
ExceptionAddress: fffff800030924fa (nt!CcMapDataForOverwrite+0x000000000000005a)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000008
Attempt to read from address 0000000000000008
2: kd> kn
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr           Call Site
00 fffff880`0cb5f940 fffff800`033c362d nt!CcMapDataForOverwrite+0x5a
01 fffff880`0cb5f9d0 fffff880`012de5e3 nt!CcPreparePinWrite+0x69
02 fffff880`0cb5fa90 fffff880`012d0dd3 Ntfs!LfsAllocateLbcb+0x12f
03 fffff880`0cb5fb00 fffff880`012caf7f Ntfs!LfsPrepareLfcbForLogRecord+0x97
04 fffff880`0cb5fb30 fffff880`012d18b5 Ntfs!LfsWriteLogRecordIntoLogPage+0x43f
05 fffff880`0cb5fbd0 fffff880`012cd676 Ntfs!LfsWrite+0x145
06 fffff880`0cb5fc90 fffff880`012cdab4 Ntfs!NtfsWriteLog+0x466
07 fffff880`0cb5fee0 fffff880`012d7dd3 Ntfs!NtfsWriteLog+0x8a4
08 fffff880`0cb60130 fffff880`012d6a67 Ntfs!InsertSimpleAllocation+0xd3
09 fffff880`0cb601e0 fffff880`0128dd3b Ntfs!AddToIndex+0x107
0a fffff880`0cb60260 fffff880`012f259a Ntfs!NtOfsAddRecords+0x167
0b fffff880`0cb60440 fffff880`01355144 Ntfs!NtfsSetObjectIdInternal+0x1d6
0c fffff880`0cb60610 fffff880`0131adc3 Ntfs!NtfsCreateOrGetObjectId+0x484
0d fffff880`0cb60700 fffff880`012d353d Ntfs! ?? ::NNGAKEGL::`string'+0x1d16a
0e fffff880`0cb60740 fffff880`0115fbcf Ntfs!NtfsFsdFileSystemControl+0x13d
0f fffff880`0cb607e0 fffff880`0117f95e fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
10 fffff880`0cb60870 fffff800`033eaf97 fltmgr!FltpFsControl+0xee
11 fffff880`0cb608d0 fffff800`033aa8c6 nt!IopXxxControlFile+0x607
12 fffff880`0cb60a00 fffff800`030cf8d3 nt!NtFsControlFile+0x56
13 fffff880`0cb60a70 00000000`772a16aa nt!KiSystemServiceCopyEnd+0x13
14 00000000`06b4d098 00000000`00000000 0x772a16aa

1: kd> .cxr 0xfffff8800c64ec10;r
rax=0000000000000000 rbx=000000000000031c rcx=0000000000000000
rdx=fffff8800da15580 rsi=fffff8a001190c70 rdi=000000000017fffc
rip=fffff800033f44f8 rsp=fffff8800c64f5f8 rbp=fffff8a001197950
 r8=fffff8a001190c70  r9=fffffa8007a4b040 r10=0000000000015548
r11=fffff8800c64f688 r12=fffff8000300a000 r13=0000000000000000
r14=fffff8800da00050 r15=fffff8800c64f6b8
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
nt!ObpCaptureHandleInformation+0x68:
fffff800`033f44f8 8a4128          mov     al,byte ptr [rcx+28h] ds:002b:00000000`00000028=??
Last set context:
rax=0000000000000000 rbx=000000000000031c rcx=0000000000000000
rdx=fffff8800da15580 rsi=fffff8a001190c70 rdi=000000000017fffc
rip=fffff800033f44f8 rsp=fffff8800c64f5f8 rbp=fffff8a001197950
 r8=fffff8a001190c70  r9=fffffa8007a4b040 r10=0000000000015548
r11=fffff8800c64f688 r12=fffff8000300a000 r13=0000000000000000
r14=fffff8800da00050 r15=fffff8800c64f6b8
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
nt!ObpCaptureHandleInformation+0x68:
fffff800`033f44f8 8a4128          mov     al,byte ptr [rcx+28h] ds:002b:00000000`00000028=??

1: kd> kn
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr           Call Site
00 fffff880`0c64f5f8 fffff800`03470039 nt!ObpCaptureHandleInformation+0x68
01 fffff880`0c64f600 fffff800`03470717 nt!ExSnapShotHandleTables+0xe9
02 fffff880`0c64f680 fffff800`034e4f85 nt!ObGetHandleInformation+0x37
03 fffff880`0c64f6b0 fffff800`033e6413 nt!ExpGetHandleInformation+0x55
04 fffff880`0c64f6f0 fffff800`033874c9 nt! ?? ::NNGAKEGL::`string'+0x506d2
05 fffff880`0c64faa0 fffff800`0307bcd3 nt!NtQuerySystemInformation+0x4d
06 fffff880`0c64fae0 00000000`777fdf3a nt!KiSystemServiceCopyEnd+0x13
07 00000000`074ae538 00000000`00000000 0x777fdf3a

We're going to need an updated kernel dump, at the least - I'd actually prefer a complete memory dump here, given it's possible the trigger is coming from something in user-mode that has a kernel-mode driver component.

 

[phagosaurus]

How do I set it to give a complete memory dump? The only options are none, kernel and mini dump.

 

[cluberti]

You must have a paging file that's at least the size of RAM+257MB. If you still don't see it, you can change the registry value of CrashDumpEnabled to be equal to "1". Reboot for changes to take effect.