New
#21
Thought the issue resolved itself but it crashed again. It happened when I picked up a skype call.
Thought the issue resolved itself but it crashed again. It happened when I picked up a skype call.
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).
I already uninstalled uxpatch as instructed earlier. I installed that like 2 years ago and it has never caused an issue.
You've got dumps in here still showing it loaded (and crashing the system). I would say that your uninstall was.... unsuccessful.
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.
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).
Well, I looked in my drivers folder and there isn't a uxpatch.sys so I assume that it is no longer installed.
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.
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/lywt4sfkrm...EMORY.zip?dl=0
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).
Code: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 0x772a16aaWe'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.Code: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