Windows 8.1 BSOD: No Event Report / Memory Dump/ Reboot fails. Stuck at 0%

OSR_Community_User · October 20, 2014, 7:32pm

Thank you in advance for your time, NTDEV!

Pre-Setup *(4gb of ram)*:

System Properties -> Advanced -> Startup and Recovery

Write an event to the system log: Checked.
Automatically Restart: Checked.
Write Debugging information: Kernel Memory Dump (tested will all options FYI)
Dump File: c:\memory.DMP
Overwrite any existing File: Checked.

System Properties -> Advanced -> Performance -> Advanced -> Virtual Memory

Automatically manage paging file size for all drives: UNCHECKED.
C: 8192 -> 16384
Custom size:
a. Initial size (MB): 8192
b. Maximum size (MB): 16384

Description of the problem:

No Event report is generated on BSO.
No memory.dmp is created.
No restart of the system happens.

The progress stays at 0%, and never completes.

I’m sure I must be missing something… but I can’t get any kind of dump from the crash.

Alex_Grig · October 20, 2014, 7:37pm

How big is the disk?
Why did you want to change the dump location and the paging file size?

OSR_Community_User · October 20, 2014, 7:41pm

280gb. (100+gb free)
a.Article that said the dump location needed to be where the page file
was located, this was ensuring it was located there.
b. Article that said that if the page file size was not at least as big
as ram, then no dump file would be created.

On Mon, Oct 20, 2014 at 4:36 PM, wrote:

> 1. How big is the disk?
> 2. Why did you want to change the dump location and the paging file size?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Thanks in advance,
Roscoe Casita

Alex_Grig · October 20, 2014, 8:28pm

The dump location needs to be on the same drive as pagefile.sys. Doesn’t have to be in the same root directory. The default dump location is in \Windows
The default page file size IS at least as big (+50%) as RAM.

OSR_Community_User · October 20, 2014, 8:33pm

Aye, but I’m still not getting dump files. That’s the weird part.
On Oct 20, 2014 5:28 PM, wrote:

> 2. The dump location needs to be on the same drive as pagefile.sys.
> Doesn’t have to be in the same root directory. The default dump location is
> in \Windows
> 3. The default page file size IS at least as big (+50%) as RAM.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · October 20, 2014, 8:41pm

>Aye, but I’m still not getting dump files. That’s the weird part.

Can you configure this machine for kernel debugging and attach a debugger ?

Of course you need a second machine to do this.

OSR_Community_User · October 20, 2014, 8:45pm

I’ll give it a shot. I can do that, but I actually need to generate the
dump to send to another individual. I’ve never had this problem of no event
reporting/ no dump file / no reboot.

Once I’m attached with a debugger at the halt point, is there a way to
generate a dump file in windbg?

Sorry, still learning some ropes here.
On Oct 20, 2014 5:42 PM, wrote:

> >Aye, but I’m still not getting dump files. That’s the weird part.
>
> Can you configure this machine for kernel debugging and attach a debugger ?
>
> Of course you need a second machine to do this.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · October 20, 2014, 8:56pm

Look at thus page:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff562428(v=vs.85).aspx

OSR_Community_User · October 20, 2014, 9:23pm

Awesome, thank you! That will solve the problem.

What could be the problem on this pc though?

On Mon, Oct 20, 2014 at 5:55 PM, wrote:

> Look at thus page:
>
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff562428(v=vs.85).aspx
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Thanks in advance,
Roscoe Casita

OSR_Community_User · October 20, 2014, 10:17pm

>What could be the problem on this pc though?

I don’t know. Maybe a registred bugcheck callback is causing a deadlock. The debugger should help you find who is actually locked if that is the case.

Alex_Grig · October 20, 2014, 10:55pm

What type of system disk is it? ATA/SATA or SCSI? If SCSI, what HBA?

OSR_Community_User · October 21, 2014, 11:50am

Type of disk is SATA

Got the system attached to the debugger: !analyze -v output:

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffcf80ebcbec90, memory referenced
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation
Arg3: fffff801921f4119, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, (reserved)

Debugging Details:

WRITE_ADDRESS: ffffcf80ebcbec90 Special pool

FAULTING_IP:
usbser+9119
fffff801`921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh

MM_INTERNAL_CODE: 0

IMAGE_NAME: usbser.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5215f890

MODULE_NAME: usbser

FAULTING_MODULE: fffff801921eb000 usbser

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xD5

PROCESS_NAME: System

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

TRAP_FRAME: ffffd001640d2710 – (.trap 0xffffd001640d2710)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=ffffe0016edf5290 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801921f4119 rsp=ffffd001640d28a0 rbp=ffffe0016d4411c0
r8=ffffe0016edf5290 r9=ffffe001705b2110 r10=fffff80393ca8780
r11=ffffe0017063f9b0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
usbser+0x9119:
fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh ds:0000000000000030=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff803937efa46 to fffff8039376cb90

STACK_TEXT:
ffffd001640d1d78 fffff803937efa46 : 0000000000000000 0000000000000000
ffffd001640d1ee0 fffff8039365c8cc : nt!DbgBreakPointWithStatus
ffffd001640d1d80 fffff803937ef357 : 0000000000000003 ffffd001640d1ee0
fffff80393773fd0 ffffd001640d2430 : nt!KiBugCheckDebugBreak+0x12
ffffd001640d1de0 fffff803937660a4 : 7803938c90000000 0000000000000000
0000000000000040 fffff80393c8bbfd : nt!KeBugCheck2+0x8ab
ffffd001640d24f0 fffff803937970e7 : 0000000000000050 ffffcf80ebcbec90
0000000000000001 ffffd001640d2710 : nt!KeBugCheckEx+0x104
ffffd001640d2530 fffff803936799c9 : 0000000000000001 ffffe0016c89e040
ffffd001640d2710 ffffe001705ffa38 : nt! ?? ::FNODOBFM::string'+0x20c37 ffffd001640d25d0 fffff8039377022f : 0000000000000001 0000000000000000 0000000000000000 ffffd001640d2710 : nt!MmAccessFault+0x7a9 ffffd001640d2710 fffff801921f4119 : 0000000000000000 ffffe0016d4411c0 ffffcf80ebcbec60 0000000000000002 : nt!KiPageFault+0x12f ffffd001640d28a0 fffff8018f2d0572 : ffffe0016d441070 ffffd001640d2940 ffffcf80ebcbec60 fffff801921f4000 : usbser+0x9119 ffffd001640d2910 fffff80393c7b911 : ffffcf80ebcbec60 0000000000000002 ffffe0017033c4b0 0000000000000000 : VerifierExt!xdv_IRP_MJ_INTERNAL_DEVICE_CONTROL_wrapper+0xfe ffffd001640d2970 fffff80393c97ec9 : ffffcf80ebcbec60 ffffe001705852c0 0000000000000002 ffffe00170048240 : nt!IovCallDriver+0x3cd ffffd001640d29c0 fffff80393c7b911 : ffffe00170585410 ffffcf80ebcbec60 fffff8039372e50c ffffe001705852c0 : nt!ViFilterDispatchGeneric+0xd1 ffffd001640d2a00 fffff8018f2c9989 : ffffcf80ebcbec60 fffff80192008ed9 fffff8039372e50c ffffe0017026fe70 : nt!IovCallDriver+0x3cd ffffd001640d2a50 fffff80192008ed9 : ffffe0016ee44101 ffffe001705852c0 ffffd001640d2bd8 0000000000000000 : VerifierExt!IofCallDriver_internal_wrapper+0x71 ffffd001640d2a90 fffff801920086d2 : ffffe0016ee441a0 ffffd001640d2c00 0000000000000000 fffff80393c8be8f : serenum!Serenum_IoSyncIoctlEx+0x85 ffffd001640d2b00 fffff801920014a6 : ffffe0016ee441a0 000000000000001f 0000000000000008 ffffe0016ee441a0 : serenum!Serenum_ReenumerateDevices+0x1c6 ffffd001640d2d10 fffff803936e1794 : 0000000000000001 ffffe0016c89e040 0000000000000080 ffffe0016c89e040 : serenum!SerenumEnumThread+0x6a ffffd001640d2d40 fffff8039376c5c6 : fffff803938f8180 ffffe0016c89e040 ffffe00170574080 ffffd0015e746628 : nt!PspSystemThreadStartup+0x58 ffffd001640d2da0 0000000000000000 : ffffd001640d3000 ffffd001640cd000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
usbser+9119
fffff801`921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: usbser+9119

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0xD5_VRF_usbser+9119

BUCKET_ID: 0xD5_VRF_usbser+9119

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xd5_vrf_usbser+9119

FAILURE_ID_HASH: {27c7dfca-273e-d435-f580-6ab7617b2908}

Followup: MachineOwner

On Mon, Oct 20, 2014 at 7:53 PM, wrote:

> What type of system disk is it? ATA/SATA or SCSI? If SCSI, what HBA?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Thanks in advance,
Roscoe Casita

OSR_Community_User · October 21, 2014, 12:25pm

FYI I did get the dump off the machine, but the real problem still remains:
the machine does not generate a dump automatically.

On Tue, Oct 21, 2014 at 8:49 AM, Roscoe Casita
wrote:

> Type of disk is SATA
>
> 1. Got the system attached to the debugger: !analyze -v output:
>
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
> Memory was referenced after it was freed.
> This cannot be protected by try-except.
> When possible, the guilty driver’s name (Unicode string) is printed on
> the bugcheck screen and saved in KiBugCheckDriver.
> Arguments:
> Arg1: ffffcf80ebcbec90, memory referenced
> Arg2: 0000000000000001, value 0 = read operation, 1 = write operation
> Arg3: fffff801921f4119, if non-zero, the address which referenced memory.
> Arg4: 0000000000000000, (reserved)
>
> Debugging Details:
> ------------------
>
>
> WRITE_ADDRESS: ffffcf80ebcbec90 Special pool
>
> FAULTING_IP:
> usbser+9119
> fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh > > MM_INTERNAL_CODE: 0 > > IMAGE_NAME: usbser.sys > > DEBUG_FLR_IMAGE_TIMESTAMP: 5215f890 > > MODULE_NAME: usbser > > FAULTING_MODULE: fffff801921eb000 usbser > > DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT > > BUGCHECK_STR: 0xD5 > > PROCESS_NAME: System > > CURRENT_IRQL: 0 > > ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre > > TRAP_FRAME: ffffd001640d2710 -- (.trap 0xffffd001640d2710) > NOTE: The trap frame does not contain all registers. > Some register values may be zeroed or incorrect. > rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000 > rdx=ffffe0016edf5290 rsi=0000000000000000 rdi=0000000000000000 > rip=fffff801921f4119 rsp=ffffd001640d28a0 rbp=ffffe0016d4411c0 > r8=ffffe0016edf5290 r9=ffffe001705b2110 r10=fffff80393ca8780 > r11=ffffe0017063f9b0 r12=0000000000000000 r13=0000000000000000 > r14=0000000000000000 r15=0000000000000000 > iopl=0 nv up ei ng nz na po nc > usbser+0x9119: > fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh
> ds:0000000000000030=???????? > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff803937efa46 to fffff8039376cb90 > > STACK_TEXT: > ffffd001640d1d78 fffff803937efa46 : 0000000000000000 0000000000000000 > ffffd001640d1ee0 fffff8039365c8cc : nt!DbgBreakPointWithStatus > ffffd001640d1d80 fffff803937ef357 : 0000000000000003 ffffd001640d1ee0 > fffff80393773fd0 ffffd001640d2430 : nt!KiBugCheckDebugBreak+0x12 > ffffd001640d1de0 fffff803937660a4 : 7803938c90000000 0000000000000000 > 0000000000000040 fffff80393c8bbfd : nt!KeBugCheck2+0x8ab > ffffd001640d24f0 fffff803937970e7 : 0000000000000050 ffffcf80ebcbec90 > 0000000000000001 ffffd001640d2710 : nt!KeBugCheckEx+0x104 > ffffd001640d2530 fffff803936799c9 : 0000000000000001 ffffe0016c89e040 > ffffd001640d2710 ffffe001705ffa38 : nt! ?? ::FNODOBFM::string’+0x20c37
> ffffd001640d25d0 fffff8039377022f : 0000000000000001 0000000000000000
> 0000000000000000 ffffd001640d2710 : nt!MmAccessFault+0x7a9
> ffffd001640d2710 fffff801921f4119 : 0000000000000000 ffffe0016d4411c0
> ffffcf80ebcbec60 0000000000000002 : nt!KiPageFault+0x12f
> ffffd001640d28a0 fffff8018f2d0572 : ffffe0016d441070 ffffd001640d2940
> ffffcf80ebcbec60 fffff801921f4000 : usbser+0x9119
> ffffd001640d2910 fffff80393c7b911 : ffffcf80ebcbec60 0000000000000002
> ffffe0017033c4b0 0000000000000000 :
> VerifierExt!xdv_IRP_MJ_INTERNAL_DEVICE_CONTROL_wrapper+0xfe
> ffffd001640d2970 fffff80393c97ec9 : ffffcf80ebcbec60 ffffe001705852c0
> 0000000000000002 ffffe00170048240 : nt!IovCallDriver+0x3cd
> ffffd001640d29c0 fffff80393c7b911 : ffffe00170585410 ffffcf80ebcbec60
> fffff8039372e50c ffffe001705852c0 : nt!ViFilterDispatchGeneric+0xd1
> ffffd001640d2a00 fffff8018f2c9989 : ffffcf80ebcbec60 fffff80192008ed9
> fffff8039372e50c ffffe0017026fe70 : nt!IovCallDriver+0x3cd
> ffffd001640d2a50 fffff80192008ed9 : ffffe0016ee44101 ffffe001705852c0
> ffffd001640d2bd8 0000000000000000 :
> VerifierExt!IofCallDriver_internal_wrapper+0x71
> ffffd001640d2a90 fffff801920086d2 : ffffe0016ee441a0 ffffd001640d2c00
> 0000000000000000 fffff80393c8be8f : serenum!Serenum_IoSyncIoctlEx+0x85
> ffffd001640d2b00 fffff801920014a6 : ffffe0016ee441a0 000000000000001f
> 0000000000000008 ffffe0016ee441a0 :
> serenum!Serenum_ReenumerateDevices+0x1c6
> ffffd001640d2d10 fffff803936e1794 : 0000000000000001 ffffe0016c89e040
> 0000000000000080 ffffe0016c89e040 : serenum!SerenumEnumThread+0x6a
> ffffd001640d2d40 fffff8039376c5c6 : fffff803938f8180 ffffe0016c89e040
> ffffe00170574080 ffffd0015e746628 : nt!PspSystemThreadStartup+0x58
> ffffd001640d2da0 0000000000000000 : ffffd001640d3000 ffffd001640cd000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> usbser+9119
> fffff801`921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh
>
> SYMBOL_STACK_INDEX: 7
>
> SYMBOL_NAME: usbser+9119
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: 0xD5_VRF_usbser+9119
>
> BUCKET_ID: 0xD5_VRF_usbser+9119
>
> ANALYSIS_SOURCE: KM
>
> FAILURE_ID_HASH_STRING: km:0xd5_vrf_usbser+9119
>
> FAILURE_ID_HASH: {27c7dfca-273e-d435-f580-6ab7617b2908}
>
> Followup: MachineOwner
> ---------
>
>
> On Mon, Oct 20, 2014 at 7:53 PM, wrote:
>
>> What type of system disk is it? ATA/SATA or SCSI? If SCSI, what HBA?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Thanks in advance,
> Roscoe Casita
>

–
Thanks in advance,
Roscoe Casita

OSR_Community_User · October 21, 2014, 5:19pm

Are dump files generated when Driver Verified is enabled?

On Tue, Oct 21, 2014 at 9:24 AM, Roscoe Casita
wrote:

> FYI I did get the dump off the machine, but the real problem still
> remains: the machine does not generate a dump automatically.
>
> On Tue, Oct 21, 2014 at 8:49 AM, Roscoe Casita
> wrote:
>
>> Type of disk is SATA
>>
>> 1. Got the system attached to the debugger: !analyze -v output:
>>
>>
>> *****
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>>
>>
>> DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
>> Memory was referenced after it was freed.
>> This cannot be protected by try-except.
>> When possible, the guilty driver’s name (Unicode string) is printed on
>> the bugcheck screen and saved in KiBugCheckDriver.
>> Arguments:
>> Arg1: ffffcf80ebcbec90, memory referenced
>> Arg2: 0000000000000001, value 0 = read operation, 1 = write operation
>> Arg3: fffff801921f4119, if non-zero, the address which referenced memory.
>> Arg4: 0000000000000000, (reserved)
>>
>> Debugging Details:
>> ------------------
>>
>>
>> WRITE_ADDRESS: ffffcf80ebcbec90 Special pool
>>
>> FAULTING_IP:
>> usbser+9119
>> fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh >> >> MM_INTERNAL_CODE: 0 >> >> IMAGE_NAME: usbser.sys >> >> DEBUG_FLR_IMAGE_TIMESTAMP: 5215f890 >> >> MODULE_NAME: usbser >> >> FAULTING_MODULE: fffff801921eb000 usbser >> >> DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT >> >> BUGCHECK_STR: 0xD5 >> >> PROCESS_NAME: System >> >> CURRENT_IRQL: 0 >> >> ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre >> >> TRAP_FRAME: ffffd001640d2710 -- (.trap 0xffffd001640d2710) >> NOTE: The trap frame does not contain all registers. >> Some register values may be zeroed or incorrect. >> rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000 >> rdx=ffffe0016edf5290 rsi=0000000000000000 rdi=0000000000000000 >> rip=fffff801921f4119 rsp=ffffd001640d28a0 rbp=ffffe0016d4411c0 >> r8=ffffe0016edf5290 r9=ffffe001705b2110 r10=fffff80393ca8780 >> r11=ffffe0017063f9b0 r12=0000000000000000 r13=0000000000000000 >> r14=0000000000000000 r15=0000000000000000 >> iopl=0 nv up ei ng nz na po nc >> usbser+0x9119: >> fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh
>> ds:0000000000000030=???????? >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff803937efa46 to fffff8039376cb90 >> >> STACK_TEXT: >> ffffd001640d1d78 fffff803937efa46 : 0000000000000000 0000000000000000 >> ffffd001640d1ee0 fffff8039365c8cc : nt!DbgBreakPointWithStatus >> ffffd001640d1d80 fffff803937ef357 : 0000000000000003 ffffd001640d1ee0 >> fffff80393773fd0 ffffd001640d2430 : nt!KiBugCheckDebugBreak+0x12 >> ffffd001640d1de0 fffff803937660a4 : 7803938c90000000 0000000000000000 >> 0000000000000040 fffff80393c8bbfd : nt!KeBugCheck2+0x8ab >> ffffd001640d24f0 fffff803937970e7 : 0000000000000050 ffffcf80ebcbec90 >> 0000000000000001 ffffd001640d2710 : nt!KeBugCheckEx+0x104 >> ffffd001640d2530 fffff803936799c9 : 0000000000000001 ffffe0016c89e040 >> ffffd001640d2710 ffffe001705ffa38 : nt! ?? ::FNODOBFM::string’+0x20c37
>> ffffd001640d25d0 fffff8039377022f : 0000000000000001 0000000000000000
>> 0000000000000000 ffffd001640d2710 : nt!MmAccessFault+0x7a9
>> ffffd001640d2710 fffff801921f4119 : 0000000000000000 ffffe0016d4411c0
>> ffffcf80ebcbec60 0000000000000002 : nt!KiPageFault+0x12f
>> ffffd001640d28a0 fffff8018f2d0572 : ffffe0016d441070 ffffd001640d2940
>> ffffcf80ebcbec60 fffff801921f4000 : usbser+0x9119
>> ffffd001640d2910 fffff80393c7b911 : ffffcf80ebcbec60 0000000000000002
>> ffffe0017033c4b0 0000000000000000 :
>> VerifierExt!xdv_IRP_MJ_INTERNAL_DEVICE_CONTROL_wrapper+0xfe
>> ffffd001640d2970 fffff80393c97ec9 : ffffcf80ebcbec60 ffffe001705852c0
>> 0000000000000002 ffffe00170048240 : nt!IovCallDriver+0x3cd
>> ffffd001640d29c0 fffff80393c7b911 : ffffe00170585410 ffffcf80ebcbec60
>> fffff8039372e50c ffffe001705852c0 : nt!ViFilterDispatchGeneric+0xd1
>> ffffd001640d2a00 fffff8018f2c9989 : ffffcf80ebcbec60 fffff80192008ed9
>> fffff8039372e50c ffffe0017026fe70 : nt!IovCallDriver+0x3cd
>> ffffd001640d2a50 fffff80192008ed9 : ffffe0016ee44101 ffffe001705852c0
>> ffffd001640d2bd8 0000000000000000 :
>> VerifierExt!IofCallDriver_internal_wrapper+0x71
>> ffffd001640d2a90 fffff801920086d2 : ffffe0016ee441a0 ffffd001640d2c00
>> 0000000000000000 fffff80393c8be8f : serenum!Serenum_IoSyncIoctlEx+0x85
>> ffffd001640d2b00 fffff801920014a6 : ffffe0016ee441a0 000000000000001f
>> 0000000000000008 ffffe0016ee441a0 :
>> serenum!Serenum_ReenumerateDevices+0x1c6
>> ffffd001640d2d10 fffff803936e1794 : 0000000000000001 ffffe0016c89e040
>> 0000000000000080 ffffe0016c89e040 : serenum!SerenumEnumThread+0x6a
>> ffffd001640d2d40 fffff8039376c5c6 : fffff803938f8180 ffffe0016c89e040
>> ffffe00170574080 ffffd0015e746628 : nt!PspSystemThreadStartup+0x58
>> ffffd001640d2da0 0000000000000000 : ffffd001640d3000 ffffd001640cd000
>> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>>
>>
>> STACK_COMMAND: kb
>>
>> FOLLOWUP_IP:
>> usbser+9119
>> fffff801`921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh
>>
>> SYMBOL_STACK_INDEX: 7
>>
>> SYMBOL_NAME: usbser+9119
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> FAILURE_BUCKET_ID: 0xD5_VRF_usbser+9119
>>
>> BUCKET_ID: 0xD5_VRF_usbser+9119
>>
>> ANALYSIS_SOURCE: KM
>>
>> FAILURE_ID_HASH_STRING: km:0xd5_vrf_usbser+9119
>>
>> FAILURE_ID_HASH: {27c7dfca-273e-d435-f580-6ab7617b2908}
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>> On Mon, Oct 20, 2014 at 7:53 PM, wrote:
>>
>>> What type of system disk is it? ATA/SATA or SCSI? If SCSI, what HBA?
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> –
>> Thanks in advance,
>> Roscoe Casita
>>
>
>
>
> –
> Thanks in advance,
> Roscoe Casita
>

–
Thanks in advance,
Roscoe Casita

Doron_Holan · October 21, 2014, 5:22pm

Yes

From: Roscoe Casitamailto:xxxxx
Sent: ?10/?21/?2014 2:18 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Windows 8.1 BSOD: No Event Report / Memory Dump/ Reboot fails. Stuck at 0%

Are dump files generated when Driver Verified is enabled?

On Tue, Oct 21, 2014 at 9:24 AM, Roscoe Casita > wrote:
FYI I did get the dump off the machine, but the real problem still remains: the machine does not generate a dump automatically.

On Tue, Oct 21, 2014 at 8:49 AM, Roscoe Casita > wrote:
Type of disk is SATA

1. Got the system attached to the debugger: !analyze -v output:

Bugcheck Analysis

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffffcf80ebcbec90, memory referenced
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation
Arg3: fffff801921f4119, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, (reserved)

Debugging Details:
------------------

WRITE_ADDRESS: ffffcf80ebcbec90 Special pool

FAULTING_IP:
usbser+9119
fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh MM_INTERNAL_CODE: 0 IMAGE_NAME: usbser.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5215f890 MODULE_NAME: usbser FAULTING_MODULE: fffff801921eb000 usbser DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: 0xD5 PROCESS_NAME: System CURRENT_IRQL: 0 ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre TRAP_FRAME: ffffd001640d2710 -- (.trap 0xffffd001640d2710) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000 rdx=ffffe0016edf5290 rsi=0000000000000000 rdi=0000000000000000 rip=fffff801921f4119 rsp=ffffd001640d28a0 rbp=ffffe0016d4411c0 r8=ffffe0016edf5290 r9=ffffe001705b2110 r10=fffff80393ca8780 r11=ffffe0017063f9b0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po nc usbser+0x9119: fffff801921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh ds:0000000000000030=???????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff803937efa46 to fffff8039376cb90 STACK_TEXT: ffffd001640d1d78 fffff803937efa46 : 0000000000000000 0000000000000000 ffffd001640d1ee0 fffff8039365c8cc : nt!DbgBreakPointWithStatus ffffd001640d1d80 fffff803937ef357 : 0000000000000003 ffffd001640d1ee0 fffff80393773fd0 ffffd001640d2430 : nt!KiBugCheckDebugBreak+0x12 ffffd001640d1de0 fffff803937660a4 : 7803938c90000000 0000000000000000 0000000000000040 fffff80393c8bbfd : nt!KeBugCheck2+0x8ab ffffd001640d24f0 fffff803937970e7 : 0000000000000050 ffffcf80ebcbec90 0000000000000001 ffffd001640d2710 : nt!KeBugCheckEx+0x104 ffffd001640d2530 fffff803936799c9 : 0000000000000001 ffffe0016c89e040 ffffd001640d2710 ffffe001705ffa38 : nt! ?? ::FNODOBFM::string’+0x20c37
ffffd001640d25d0 fffff8039377022f : 0000000000000001 0000000000000000 0000000000000000 ffffd001640d2710 : nt!MmAccessFault+0x7a9
ffffd001640d2710 fffff801921f4119 : 0000000000000000 ffffe0016d4411c0 ffffcf80ebcbec60 0000000000000002 : nt!KiPageFault+0x12f
ffffd001640d28a0 fffff8018f2d0572 : ffffe0016d441070 ffffd001640d2940 ffffcf80ebcbec60 fffff801921f4000 : usbser+0x9119
ffffd001640d2910 fffff80393c7b911 : ffffcf80ebcbec60 0000000000000002 ffffe0017033c4b0 0000000000000000 : VerifierExt!xdv_IRP_MJ_INTERNAL_DEVICE_CONTROL_wrapper+0xfe
ffffd001640d2970 fffff80393c97ec9 : ffffcf80ebcbec60 ffffe001705852c0 0000000000000002 ffffe00170048240 : nt!IovCallDriver+0x3cd
ffffd001640d29c0 fffff80393c7b911 : ffffe00170585410 ffffcf80ebcbec60 fffff8039372e50c ffffe001705852c0 : nt!ViFilterDispatchGeneric+0xd1
ffffd001640d2a00 fffff8018f2c9989 : ffffcf80ebcbec60 fffff80192008ed9 fffff8039372e50c ffffe0017026fe70 : nt!IovCallDriver+0x3cd
ffffd001640d2a50 fffff80192008ed9 : ffffe0016ee44101 ffffe001705852c0 ffffd001640d2bd8 0000000000000000 : VerifierExt!IofCallDriver_internal_wrapper+0x71
ffffd001640d2a90 fffff801920086d2 : ffffe0016ee441a0 ffffd001640d2c00 0000000000000000 fffff80393c8be8f : serenum!Serenum_IoSyncIoctlEx+0x85
ffffd001640d2b00 fffff801920014a6 : ffffe0016ee441a0 000000000000001f 0000000000000008 ffffe0016ee441a0 : serenum!Serenum_ReenumerateDevices+0x1c6
ffffd001640d2d10 fffff803936e1794 : 0000000000000001 ffffe0016c89e040 0000000000000080 ffffe0016c89e040 : serenum!SerenumEnumThread+0x6a
ffffd001640d2d40 fffff8039376c5c6 : fffff803938f8180 ffffe0016c89e040 ffffe00170574080 ffffd0015e746628 : nt!PspSystemThreadStartup+0x58
ffffd001640d2da0 0000000000000000 : ffffd001640d3000 ffffd001640cd000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
usbser+9119
fffff801`921f4119 c746300d0000c0 mov dword ptr [rsi+30h],0C000000Dh

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: usbser+9119

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0xD5_VRF_usbser+9119

BUCKET_ID: 0xD5_VRF_usbser+9119

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xd5_vrf_usbser+9119

FAILURE_ID_HASH: {27c7dfca-273e-d435-f580-6ab7617b2908}

Followup: MachineOwner
---------

On Mon, Oct 20, 2014 at 7:53 PM, > wrote:
What type of system disk is it? ATA/SATA or SCSI? If SCSI, what HBA?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Thanks in advance,
Roscoe Casita

–
Thanks in advance,
Roscoe Casita

–
Thanks in advance,
Roscoe Casita
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>