BSOD!!! (bugcheck 0x3b)

Jin_K · November 14, 2012, 9:12pm

hi all

My driver every time the computer is shut down, blue screen occurs. (only win7 64bit)

==========================================================
Here is the !analyze -v:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff88001077b86, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800a93ec50, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

PEB is paged out (Peb.Ldr = 000007fffffdd018). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 000007fffffdd018). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx

FAULTING_IP:
fltmgr!FltpGetStreamListCtrl+166
fffff880`01077b86 488910 mov qword ptr [rax],rdx

CONTEXT: fffff8800a93ec50 – (.cxr 0xfffff8800a93ec50)
rax=0000000000000000 rbx=fffffa800b6c9f20 rcx=fffffa8007e9cd70
rdx=fffffa800d167930 rsi=fffffa8007e9c800 rdi=fffff8800a93f6f8
rip=fffff88001077b86 rsp=fffff8800a93f630 rbp=0000000000000000
r8=fffffa800d167900 r9=fffff8800a93f6f8 r10=fffff880010905c0
r11=fffffa800d167900 r12=fffffa800d167900 r13=fffffa8006718ac0
r14=fffffa8009058010 r15=fffff8800a93f8b0
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
fltmgr!FltpGetStreamListCtrl+0x166:
fffff88001077b86 488910 mov qword ptr [rax],rdx ds:002b:0000000000000000=???
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: TrustedInstall

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff88001098841 to fffff88001077b86

STACK_TEXT:
fffff8800a93f630 fffff88001098841 : fffffa8007e9c800 fffffa800bea0c40 0000000000000001 fffffa800d167900 : fltmgr!FltpGetStreamListCtrl+0x166
fffff8800a93f690 fffff8800109dbc1 : fffffa8007841010 0000000000000000 000000000a4cf264 0000000000000000 : fltmgr!FltpInvalidateNameCaching+0x31
fffff8800a93f6e0 fffff880010756ec : fffffa800e38e980 fffffa80090586b0 fffffa800e38e830 0000000010000004 : fltmgr! ?? ::NNGAKEGL::string'+0x1bba fffff8800a93f710 fffff88001076329 : fffff8800a93f800 fffff8800a93f906 fffff8800a93f800 fffffa8000000000 : fltmgr!FltpPerformPreCallbacks+0x97c fffff8800a93f810 fffff880010746c7 : fffffa800cdce9f0 fffffa80075246c0 fffffa8007687de0 fffffa8000000030 : fltmgr!FltpPassThrough+0x2d9 fffff8800a93f890 fffff8800a4a6944 : fffffa800cdce9f0 01cc6d42af845ce4 01cc6a5b84646f1a 01cc6d42af845ce4 : fltmgr!FltpDispatch+0xb7 fffff8800a93f8f0 fffff8800a4cbdc4 : 00000000000000d2 fffff8800a93fb60 fffffa800cdce9f0 fffffa800cdce9f0 : mcstrg!DLPMediaControlPassThrough+0xe4 [d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c @ 817] fffff8800a93f920 fffff8000376c063 : 00000000000000d2 fffff8800a93fb60 0000000000000000 fffffa800b6e3a70 : nmlhssrv01!FsFilterDispatchPassThrough+0x2c [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 202] fffff8800a93f950 fffff8000348bed3 : 0000000000000240 fffffa800965e060 0000000000e4d478 00000980000000d2 : nt!NtSetInformationFile+0x91f fffff8800a93fa70 0000000076f9158a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 0000000000e4d458 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x76f9158a

FOLLOWUP_IP:
mcstrg!DLPMediaControlPassThrough+e4 [d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c @ 817]
fffff880`0a4a6944 488b5c2430 mov rbx,qword ptr [rsp+30h]

FAULTING_SOURCE_CODE:
No source found for ‘d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c’

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: mcstrg!DLPMediaControlPassThrough+e4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mcstrg

IMAGE_NAME: mcstrg.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4dbac95c

STACK_COMMAND: .cxr 0xfffff8800a93ec50 ; kb

FAILURE_BUCKET_ID: X64_0x3B_mcstrg!DLPMediaControlPassThrough+e4

BUCKET_ID: X64_0x3B_mcstrg!DLPMediaControlPassThrough+e4

Followup: MachineOwner

==========================================================

Source code:
mcstrg!DLPMediaControlPassThrough & nmlhssrv01!FsFilterDispatchPassThrough

PFSFILTER_DEVICE_EXTENSION pDevExt = (PFSFILTER_DEVICE_EXTENSION)
DeviceObject->DeviceExtension;

if (DeviceObject == g_pDeviceObject)
{
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}

IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(pDevExt->AttachedToDeviceObject, Irp);

==========================================================
added

6: kd> kn

Child-SP RetAddr Call Site

00 fffff88009dfd388 fffff800036d4569 nt!KeBugCheckEx
01 fffff88009dfd390 fffff800036d3ebc nt!KiBugCheckDispatch+0x69
02 fffff88009dfd4d0 fffff800036ffaed nt!KiSystemServiceHandler+0x7c
03 fffff88009dfd510 fffff800036fe8c5 nt!RtlpExecuteHandlerForException+0xd
04 fffff88009dfd540 fffff8000370f851 nt!RtlDispatchException+0x415
05 fffff88009dfdc20 fffff800036d4642 nt!KiDispatchException+0x135
06 fffff88009dfe2c0 fffff800036d31ba nt!KiExceptionDispatch+0xc2
07 fffff88009dfe4a0 fffff880010ecb86 nt!KiPageFault+0x23a
08 fffff88009dfe630 fffff8800110d841 fltmgr!FltpGetStreamListCtrl+0x166
09 fffff88009dfe690 fffff88001112bc1 fltmgr!FltpInvalidateNameCaching+0x31
0a fffff88009dfe6e0 fffff880010ea6ec fltmgr! ?? ::NNGAKEGL::string'+0x1bba 0b fffff88009dfe710 fffff880010eb329 fltmgr!FltpPerformPreCallbacks+0x97c 0c fffff88009dfe810 fffff880010e96c7 fltmgr!FltpPassThrough+0x2d9 0d fffff88009dfe890 fffff88009979b0c fltmgr!FltpDispatch+0xb7 0e fffff88009dfe8f0 fffff88009999dd8 mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944] 0f fffff88009dfe920 fffff800039afbc3 nmlhssrv01!FsFilterDispatchPassThrough+0x40 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 204] 10 fffff88009dfe950 fffff800036d4253 nt!NtSetInformationFile+0x91f 11 fffff88009dfea70 00000000777b158a nt!KiSystemServiceCopyEnd+0x13 12 000000001a35e2a8 0000000000000000 0x777b158a 6: kd\> .frame 0e 0e fffff88009dfe8f0 fffff88009999dd8 mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944] 6: kd\> dv pDevObj = 0x00000000000000b4
pIrp = 0xfffff880`09dfeb60

==========================================================
I guess…
the memory address of the pDevOdj Is something wrong?
pDevObj = 0x00000000`000000b4

What’s the problem?

Help me…

Regards

OSR_Community_User · November 14, 2012, 11:25pm

> hi all

My driver every time the computer is shut down, blue screen occurs. (only
win7 64bit)

==========================================================
Here is the !analyze -v:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff88001077b86, Address of the exception record for the exception
that caused the bugcheck
Arg3: fffff8800a93ec50, Address of the context record for the exception
that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

PEB is paged out (Peb.Ldr = 000007fffffdd018). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 000007fffffdd018). Type “.hh dbgerr001” for
details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx

FAULTING_IP:
fltmgr!FltpGetStreamListCtrl+166
fffff880`01077b86 488910 mov qword ptr [rax],rdx

CONTEXT: fffff8800a93ec50 – (.cxr 0xfffff8800a93ec50)
rax=0000000000000000 rbx=fffffa800b6c9f20 rcx=fffffa8007e9cd70
rdx=fffffa800d167930 rsi=fffffa8007e9c800 rdi=fffff8800a93f6f8
rip=fffff88001077b86 rsp=fffff8800a93f630 rbp=0000000000000000
r8=fffffa800d167900 r9=fffff8800a93f6f8 r10=fffff880010905c0
r11=fffffa800d167900 r12=fffffa800d167900 r13=fffffa8006718ac0
r14=fffffa8009058010 r15=fffff8800a93f8b0
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010202
fltmgr!FltpGetStreamListCtrl+0x166:
fffff88001077b86 488910 mov qword ptr [rax],rdx ds:002b:0000000000000000=???
Resetting default scope

Note that this indicates you are trying to dereference a NULL pointer.
Look at the instruction, and the value of rax.

So it looks like you are passing a NULL pointer in to one of the routines.
So you need to figure out what call you are doing that is picking up a
NULL pointer and why that pointer is NULL.

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: TrustedInstall

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff88001098841 to fffff88001077b86

STACK_TEXT:
fffff8800a93f630 fffff88001098841 : fffffa8007e9c800 fffffa800bea0c40
0000000000000001 fffffa800d167900 : fltmgr!FltpGetStreamListCtrl+0x166
fffff8800a93f690 fffff8800109dbc1 : fffffa8007841010 0000000000000000
000000000a4cf264 0000000000000000 :
fltmgr!FltpInvalidateNameCaching+0x31
fffff8800a93f6e0 fffff880010756ec : fffffa800e38e980 fffffa80090586b0
fffffa800e38e830 0000000010000004 : fltmgr! ??
::NNGAKEGL::string'+0x1bba fffff8800a93f710 fffff88001076329 : fffff8800a93f800 fffff8800a93f906 fffff8800a93f800 fffffa8000000000 : fltmgr!FltpPerformPreCallbacks+0x97c fffff8800a93f810 fffff880010746c7 : fffffa800cdce9f0 fffffa80075246c0 fffffa8007687de0 fffffa8000000030 : fltmgr!FltpPassThrough+0x2d9 fffff8800a93f890 fffff8800a4a6944 : fffffa800cdce9f0 01cc6d42af845ce4 01cc6a5b84646f1a 01cc6d42af845ce4 : fltmgr!FltpDispatch+0xb7 fffff8800a93f8f0 fffff8800a4cbdc4 : 00000000000000d2 fffff8800a93fb60 fffffa800cdce9f0 fffffa800cdce9f0 : mcstrg!DLPMediaControlPassThrough+0xe4 [d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c @ 817] fffff8800a93f920 fffff8000376c063 : 00000000000000d2 fffff8800a93fb60 0000000000000000 fffffa800b6e3a70 : nmlhssrv01!FsFilterDispatchPassThrough+0x2c [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 202] fffff8800a93f950 fffff8000348bed3 : 0000000000000240 fffffa800965e060 0000000000e4d478 00000980000000d2 : nt!NtSetInformationFile+0x91f fffff8800a93fa70 0000000076f9158a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 0000000000e4d458 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x76f9158a

FOLLOWUP_IP:
mcstrg!DLPMediaControlPassThrough+e4
[d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c
@ 817]
fffff880`0a4a6944 488b5c2430 mov rbx,qword ptr [rsp+30h]

FAULTING_SOURCE_CODE:
No source found for
‘d:\bsod\source\001.[2012.03.02]rollback\1.src_mediaconl_20120106\dlpremovable\main.c’

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: mcstrg!DLPMediaControlPassThrough+e4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mcstrg

IMAGE_NAME: mcstrg.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4dbac95c

STACK_COMMAND: .cxr 0xfffff8800a93ec50 ; kb

FAILURE_BUCKET_ID: X64_0x3B_mcstrg!DLPMediaControlPassThrough+e4

BUCKET_ID: X64_0x3B_mcstrg!DLPMediaControlPassThrough+e4

Followup: MachineOwner

==========================================================

Source code:
mcstrg!DLPMediaControlPassThrough & nmlhssrv01!FsFilterDispatchPassThrough

PFSFILTER_DEVICE_EXTENSION pDevExt = (PFSFILTER_DEVICE_EXTENSION)
DeviceObject->DeviceExtension;

if (DeviceObject == g_pDeviceObject)

The naming convention suggests that you have a global object. It is rare
that a driver should legitimately have a global variable, so I’d suggest a
careful examination to see if this could possibly make sense. Remember
that a global variable is common to all instances of this driver, so if it
can be set to NULL somewhere, or otherwise changed, you are already in
deep trouble. Every thread uses this same instance. A good criterion to
use is “If you code a global variable, you have made a serious coding
error”, and in the extremely few cases where you actually need one, you
will be forced to think about all the issues. For example, do you have a
lock on all accesses to this global variable? Do you know that its usage
is always thread-safe (including multiple instances of the driver)? If
your filter driver is being used in different device stacks, this would be
completely wrong.

{
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}

IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(pDevExt->AttachedToDeviceObject, Irp);

==========================================================
added

6: kd> kn

Child-SP RetAddr Call Site

00 fffff88009dfd388 fffff800036d4569 nt!KeBugCheckEx
01 fffff88009dfd390 fffff800036d3ebc nt!KiBugCheckDispatch+0x69
02 fffff88009dfd4d0 fffff800036ffaed nt!KiSystemServiceHandler+0x7c
03 fffff88009dfd510 fffff800036fe8c5
nt!RtlpExecuteHandlerForException+0xd
04 fffff88009dfd540 fffff8000370f851 nt!RtlDispatchException+0x415
05 fffff88009dfdc20 fffff800036d4642 nt!KiDispatchException+0x135
06 fffff88009dfe2c0 fffff800036d31ba nt!KiExceptionDispatch+0xc2
07 fffff88009dfe4a0 fffff880010ecb86 nt!KiPageFault+0x23a
08 fffff88009dfe630 fffff8800110d841 fltmgr!FltpGetStreamListCtrl+0x166
09 fffff88009dfe690 fffff88001112bc1
fltmgr!FltpInvalidateNameCaching+0x31
0a fffff88009dfe6e0 fffff880010ea6ec fltmgr! ??
::NNGAKEGL::string'+0x1bba 0b fffff88009dfe710 fffff880010eb329 fltmgr!FltpPerformPreCallbacks+0x97c 0c fffff88009dfe810 fffff880010e96c7 fltmgr!FltpPassThrough+0x2d9 0d fffff88009dfe890 fffff88009979b0c fltmgr!FltpDispatch+0xb7 0e fffff88009dfe8f0 fffff88009999dd8 mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944] 0f fffff88009dfe920 fffff800039afbc3 nmlhssrv01!FsFilterDispatchPassThrough+0x40 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 204] 10 fffff88009dfe950 fffff800036d4253 nt!NtSetInformationFile+0x91f 11 fffff88009dfea70 00000000777b158a nt!KiSystemServiceCopyEnd+0x13 12 000000001a35e2a8 0000000000000000 0x777b158a 6: kd\> .frame 0e 0e fffff88009dfe8f0 fffff88009999dd8 mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944] 6: kd\> dv pDevObj = 0x00000000000000b4
pIrp = 0xfffff880`09dfeb60

==========================================================
I guess…
the memory address of the pDevOdj Is something wrong?
pDevObj = 0x00000000`000000b4

You attempted to dereference a NULL pointer, and are trying to offset the
field that is 0xb4 into that pointer.

What’s the problem?

You have a NULL pointer somewhere. Sprinkling a few ASSERT statements
about the non-NULLness of various pointers might also be a good start.
But you have to look at where that NULL pointer came from.

Help me…

Regards

NTDEV is sponsored by OSR

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

Jin_K · November 15, 2012, 12:51am

Thank you, Joseph

So …pDevObj the cause of the blue screen?

Jin_K · November 15, 2012, 12:58am

Exception handling for this problem then what should I do?

OSR_Community_User · November 15, 2012, 12:37pm

> Exception handling for this problem then what should I do?

NTDEV is sponsored by OSR

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

Exce[tion handling would be the completely wrong approach. What this
means is that you have a logic error in your code, and you need to fix
that first.

Note also that it is not necessarily the pDeviceObject that is the
problem. Somebody is passing a NULL pointer to something. You have to
figure out why the pointer is NULL.

My first reaction on seeing a global variable in a driver is to find out
why it is there. 99% of the time, it is the wrong answer. 0.9% of the
time, it is the right answer, but there is no synchronization. Or
something like that. In any case, every time I look at the usage of a
global variable I find a bug in how it is used/set/read.

Find and fix your bug. Exception handling merely masks the fact that your
driver is completely messed up.
joe

Tim_Roberts · November 15, 2012, 1:44pm

xxxxx@gmail.com wrote:

Thank you, Joseph

So …pDevObj the cause of the blue screen?

We can’t tell that. FltpGetStreamListCtrl is trying to write an address
to a null pointer. We don’t know whether it was one of the parameters
you passed, or a value in a data structure, or a kernel object that you
deleted. You will have to triple-check the parameters you are passing
from your driver at the last spot you had control (in
DLPMediaControlPassThrough?).

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Alex_Grig · November 15, 2012, 3:20pm

Also, you CAN’T handle a memory access exception to the zero page in the kernel. It will bugcheck no matter what.

Jin_K · November 15, 2012, 9:34pm

Thank you all.

Umm…
DLPMediaControlPassThrough and FsFilterDispatchPassThrough is passthrough dispatch routine.
This routine uses only IoSkipCurrentIrpStackLocation & IoCallDriver.

DLPMediaControlPassThrough

===============================================================
6: kd> !thread
THREAD fffffa80098c2060 Cid 10ac.167c Teb: 000007ffffefe000 Win32Thread: 0000000000000000 RUNNING on processor 6
IRP List:
fffffa800e1f6af0: (0006,0508) Flags: 00060830 Mdl: 00000000
Not impersonating
DeviceMap fffff8a00300d880
Owning Process fffffa800c68fb30 Image: PresentationFontCache.exe
Attached Process N/A Image: N/A
Wait Start TickCount 2267769 Ticks: 0
Context Switch Count 19
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x000007feec91b184
Stack Init fffff88009dfec70 Current fffff88009dfde80
Base fffff88009dff000 Limit fffff88009df9000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff880`09dfd388 fffff800`036d4569 : 00000000`0000003b 00000000`c0000005 fffff880`010ecb86 fffff880`09dfdc50 : nt!KeBugCheckEx
fffff880`09dfd390 fffff800`036d3ebc : fffff880`09dfe3f8 fffff880`09dfdc50 00000000`00000000 fffff800`036fffe0 : nt!KiBugCheckDispatch+0x69
fffff880`09dfd4d0 fffff800`036ffaed : fffff800`038eeb74 00000000`00000000 fffff800`03656000 fffff880`09dfe3f8 : nt!KiSystemServiceHandler+0x7c
fffff880`09dfd510 fffff800`036fe8c5 : fffff800`0381c638 fffff880`09dfd588 fffff880`09dfe3f8 fffff800`03656000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`09dfd540 fffff800`0370f851 : fffff880`09dfe3f8 fffff880`09dfdc50 fffff880`00000000 fffff880`09dfe6f8 : nt!RtlDispatchException+0x415
fffff880`09dfdc20 fffff800`036d4642 : fffff880`09dfe3f8 fffffa80`0687a250 fffff880`09dfe4a0 fffffa80`07f97010 : nt!KiDispatchException+0x135
fffff880`09dfe2c0 fffff800`036d31ba : 00000000`00000001 00000000`00000000 00000000`00000200 fffffa80`0687a250 : nt!KiExceptionDispatch+0xc2
fffff880`09dfe4a0 fffff880`010ecb86 : fffffa80`0687a250 00000000`00000000 fffffa80`07f97010 fffffa80`0868fd58 : nt!KiPageFault+0x23a (TrapFrame @ fffff880`09dfe4a0) fffff880`09dfe630 fffff880`0110d841 : fffffa80`07f97010 fffffa80`09647880 00000000`00000001 fffffa80`0a08ad90 : fltmgr!FltpGetStreamListCtrl+0x166 fffff880`09dfe690 fffff880`01112bc1 : fffffa80`07887010 00000000`00000000 00000000`0999d454 00000000`00000000 : fltmgr!FltpInvalidateNameCaching+0x31 fffff880`09dfe6e0 fffff880`010ea6ec : fffffa80`0868fde0 fffffa80`092616b0 fffffa80`0868fc90 00000000`10000004 : fltmgr! ?? ::NNGAKEGL::`string’+0x1bba
fffff880`09dfe710 fffff880`010eb329 : fffff880`09dfe800 fffff880`09dfe906 fffff880`09dfe800 fffffa80`00000000 : fltmgr!FltpPerformPreCallbacks+0x97c
fffff880`09dfe810 fffff880`010e96c7 : fffffa80`0e1f6af0 fffffa80`072c2e80 fffffa80`07683b60 fffffa80`00000030 : fltmgr!FltpPassThrough+0x2d9
fffff880`09dfe890 fffff880`09979b0c : fffffa80`0e1f6af0 01cdaab8`fe15663e 01cdaab8`fe15663e 01cdaab8`fe15663e : fltmgr!FltpDispatch+0xb7
fffff880`09dfe8f0 fffff880`09999dd8 : 00000000`000000b4 fffff880`09dfeb60 fffffa80`0e1f6af0 fffffa80`0e1f6af0 : mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944]
fffff880`09dfe920 fffff800`039afbc3 : 00000000`000000b4 fffff880`09dfeb60 00000000`00000000 fffffa80`097d5760 : nmlhssrv01!FsFilterDispatchPassThrough+0x40 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 204]
fffff880`09dfe950 fffff800`036d4253 : 00000000`00000280 fffffa80`098c2060 00000000`1a35e2c8 00000980`000000b4 : nt!NtSetInformationFile+0x91f
fffff880`09dfea70 00000000`777b158a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`09dfeae0) 00000000`1a35e2a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x777b158a

DLPMediaControlPassThrough’s IoCallDriver is fltmgr!FltpDispatch is called.
Then IoCallDriver problem?

…

OSR_Community_User · November 15, 2012, 9:43pm

See below…look for >>>>>>>>>>>>> <<<<<<<<<<<<<

Thank you all.

Umm…
DLPMediaControlPassThrough and FsFilterDispatchPassThrough is passthrough
dispatch routine.
This routine uses only IoSkipCurrentIrpStackLocation & IoCallDriver.

DLPMediaControlPassThrough

===============================================================
6: kd> !thread
THREAD fffffa80098c2060 Cid 10ac.167c Teb: 000007ffffefe000 Win32Thread:
0000000000000000 RUNNING on processor 6
IRP List:
fffffa800e1f6af0: (0006,0508) Flags: 00060830 Mdl: 00000000
Not impersonating
DeviceMap fffff8a00300d880
Owning Process fffffa800c68fb30 Image:
PresentationFontCache.exe
Attached Process N/A Image: N/A
Wait Start TickCount 2267769 Ticks: 0
Context Switch Count 19
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x000007feec91b184
Stack Init fffff88009dfec70 Current fffff88009dfde80
Base fffff88009dff000 Limit fffff88009df9000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2
PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
fffff88009dfd388 fffff800036d4569 : 000000000000003b 00000000c0000005
fffff880010ecb86 fffff88009dfdc50 : nt!KeBugCheckEx
fffff88009dfd390 fffff800036d3ebc : fffff88009dfe3f8 fffff88009dfdc50
0000000000000000 fffff800036fffe0 : nt!KiBugCheckDispatch+0x69
fffff88009dfd4d0 fffff800036ffaed : fffff800038eeb74 0000000000000000
fffff80003656000 fffff88009dfe3f8 : nt!KiSystemServiceHandler+0x7c
fffff88009dfd510 fffff800036fe8c5 : fffff8000381c638 fffff88009dfd588
fffff88009dfe3f8 fffff80003656000 :
nt!RtlpExecuteHandlerForException+0xd
fffff88009dfd540 fffff8000370f851 : fffff88009dfe3f8 fffff88009dfdc50
fffff88000000000 fffff88009dfe6f8 : nt!RtlDispatchException+0x415
fffff88009dfdc20 fffff800036d4642 : fffff88009dfe3f8 fffffa800687a250
fffff88009dfe4a0 fffffa8007f97010 : nt!KiDispatchException+0x135
fffff88009dfe2c0 fffff800036d31ba : 0000000000000001 0000000000000000
0000000000000200 fffffa800687a250 : nt!KiExceptionDispatch+0xc2
fffff88009dfe4a0 fffff880010ecb86 : fffffa800687a250 0000000000000000
fffffa8007f97010 fffffa800868fd58 : nt!KiPageFault+0x23a (TrapFrame @
fffff88009dfe4a0) fffff88009dfe630 fffff8800110d841 : fffffa8007f97010 fffffa8009647880 0000000000000001 fffffa800a08ad90 : fltmgr!FltpGetStreamListCtrl+0x166 fffff88009dfe690 fffff88001112bc1 : fffffa8007887010 0000000000000000 000000000999d454 0000000000000000 : fltmgr!FltpInvalidateNameCaching+0x31 fffff88009dfe6e0 fffff880010ea6ec : fffffa800868fde0 fffffa80092616b0 fffffa800868fc90 0000000010000004 : fltmgr! ?? ::NNGAKEGL::string’+0x1bba
fffff88009dfe710 fffff880010eb329 : fffff88009dfe800 fffff88009dfe906
fffff88009dfe800 fffffa8000000000 : fltmgr!FltpPerformPreCallbacks+0x97c
fffff88009dfe810 fffff880010e96c7 : fffffa800e1f6af0 fffffa80072c2e80
fffffa8007683b60 fffffa8000000030 : fltmgr!FltpPassThrough+0x2d9
fffff88009dfe890 fffff88009979b0c : fffffa800e1f6af0 01cdaab8fe15663e
01cdaab8fe15663e 01cdaab8fe15663e : fltmgr!FltpDispatch+0xb7
fffff88009dfe8f0 fffff88009999dd8 : 00000000000000b4 fffff88009dfeb60
fffffa800e1f6af0 fffffa800e1f6af0 :
mcstrg!DLPMediaControlPassThrough+0x118
>>>>>>>>>>>>>>>>>>>>>>>
OK, this is very suspicious. Whatever the first parameter is here, it is
the derference of a NULL pointer.

<<<<<<<<<<<<<<<<<<<<<<<<

[d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c
@ 944]
>>>>>>>>>>>>>>>>>>>>>>>
This is the call site that is passing the bad pointer
<<<<<<<<<<<<<<<<<<<<<<<<

fffff88009dfe920 fffff800039afbc3 : 00000000000000b4 fffff88009dfeb60
0000000000000000 fffffa80097d5760 :
nmlhssrv01!FsFilterDispatchPassThrough+0x40
[d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c
@ 204]
fffff88009dfe950 fffff800036d4253 : 0000000000000280 fffffa80098c2060
000000001a35e2c8 00000980000000b4 : nt!NtSetInformationFile+0x91f
fffff88009dfea70 00000000777b158a : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
(TrapFrame @ fffff88009dfeae0) 000000001a35e2a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x777b158a

DLPMediaControlPassThrough’s IoCallDriver is fltmgr!FltpDispatch is
called.
Then IoCallDriver problem?

>>>>>>>>>>>>>>>>>>>>>>
I have no idea it is IoCallDriver. Have you tried looking at where these
NULL pointers are coming from? In the worst case, simply setting
conditional breakpoints looking for pointers whose values are less than
0xFFFF would be a start.
<<<<<<<<<<<<<<<<<<<<<<<

…

NTDEV is sponsored by OSR

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

Pavel_Lebedinsky · November 15, 2012, 10:13pm

NULL is a user space address so technically you *can* handle access violations resulting from dereferencing a NULL pointer.

The answer to whether you *should* be doing this is, of course, a big NO.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Thursday, November 15, 2012 12:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

Also, you CAN’T handle a memory access exception to the zero page in the kernel. It will bugcheck no matter what.

OSR_Community_User · November 15, 2012, 10:55pm

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do not
exist. In kernel mode, this is interpreted according to the active
mapping, which means that 00000000 to 0000FFFF do not exist. The fact
that they are interpreted in the lower section of memory (<2GB, <3GB, <8TB
depending on the OS configuration) doesn’t (a) change the fact that they
are invalid and (b) adding an exception handler will somehow magically
will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no alternative.

When I had to do exception handling based on illegal addresses, it was
entirely due to hardware failure. The program, as far as we could tell,
was correct. But the hardware was experimental, and we had to keep
running in spite of defective hardware. But in this case, it is clear
that the driver is defective. So you have to fix it.
joe

NULL is a user space address so technically you *can* handle access
violations resulting from dereferencing a NULL pointer.

The answer to whether you *should* be doing this is, of course, a big NO.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@broadcom.com
Sent: Thursday, November 15, 2012 12:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

Also, you CAN’T handle a memory access exception to the zero page in the
kernel. It will bugcheck no matter what.

NTDEV is sponsored by OSR

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

Pavel_Lebedinsky · November 15, 2012, 11:26pm

> In user space, addresses 00000000 to 0000FFFF do not exist.

That’s the case usually, but not always. On Windows versions prior to win8 user apps can allocate memory at NULL.

You have a bug. You have to find and fix the bug. There is no alternative.

We are in agreement here.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Thursday, November 15, 2012 7:55 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do not exist. In kernel mode, this is interpreted according to the active mapping, which means that 00000000 to 0000FFFF do not exist. The fact that they are interpreted in the lower section of memory (<2GB, <3GB, <8TB depending on the OS configuration) doesn’t (a) change the fact that they are invalid and (b) adding an exception handler will somehow magically will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no alternative.

When I had to do exception handling based on illegal addresses, it was entirely due to hardware failure. The program, as far as we could tell, was correct. But the hardware was experimental, and we had to keep running in spite of defective hardware. But in this case, it is clear that the driver is defective. So you have to fix it.
joe

NULL is a user space address so technically you *can* handle access
violations resulting from dereferencing a NULL pointer.

The answer to whether you *should* be doing this is, of course, a big NO.

OSR_Community_User · November 16, 2012, 12:03am

That’s curious. I wonder how many pieces of library code think 00000000 means invalid address. About a million lines of C code also go:

If (somePointer) {
… valid path
} else {
… invalid path
}

Sounds like they should say:

If (somePointer != INVALID_POINTER)…

Is there some specific value that is DEFINED to be an invalid address? Like for uninitialized pointers?

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel Lebedynskiy
Sent: Thursday, November 15, 2012 8:25 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

In user space, addresses 00000000 to 0000FFFF do not exist.

That’s the case usually, but not always. On Windows versions prior to win8 user apps can allocate memory at NULL.

You have a bug. You have to find and fix the bug. There is no alternative.

We are in agreement here.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Thursday, November 15, 2012 7:55 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do not exist. In kernel mode, this is interpreted according to the active mapping, which means that 00000000 to 0000FFFF do not exist. The fact that they are interpreted in the lower section of memory (<2GB, <3GB, <8TB depending on the OS configuration) doesn’t (a) change the fact that they are invalid and (b) adding an exception handler will somehow magically will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no alternative.

When I had to do exception handling based on illegal addresses, it was entirely due to hardware failure. The program, as far as we could tell, was correct. But the hardware was experimental, and we had to keep running in spite of defective hardware. But in this case, it is clear that the driver is defective. So you have to fix it.
joe

NULL is a user space address so technically you *can* handle access
violations resulting from dereferencing a NULL pointer.

The answer to whether you *should* be doing this is, of course, a big NO.

NTDEV is sponsored by OSR

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

Jin_K · November 16, 2012, 1:54am

Look at this…

6: kd> dps
fffff880`09dfe888 fffff880`010e96c7 fltmgr!FltpDispatch+0xb7
fffff880`09dfe890 fffffa80`0e1f6af0
fffff880`09dfe898 fffffa80`072c2e80
fffff880`09dfe8a0 fffffa80`07683b60
fffff880`09dfe8a8 fffffa80`00000030
fffff880`09dfe8b0 fffffa80`07887010
fffff880`09dfe8b8 fffffa80`0e1f6af0
fffff880`09dfe8c0 fffffa80`0868fc90
fffff880`09dfe8c8 ffffffff`ffffffff
fffff880`09dfe8d0 00000000`00000000
fffff880`09dfe8d8 00100002`00000200
fffff880`09dfe8e0 00000000`00000000
fffff880`09dfe8e8 fffff880`09979b0c mcstrg!DLPMediaControlPassThrough+0x118 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\1.src_mediaconl_20120106\dlpremovable\main.c @ 944]
fffff880`09dfe8f0 fffffa80`0e1f6af0
fffff880`09dfe8f8 01cdaab8`fe15663e
fffff880`09dfe900 01cdaab8`fe15663e
6: kd> dps
fffff880`09dfe908 01cdaab8`fe15663e
fffff880`09dfe910 00000000`00000000
fffff880`09dfe918 fffff880`09999dd8 nmlhssrv01!FsFilterDispatchPassThrough+0x40 [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\irpdispatch.c @ 204]
fffff880`09dfe920 00000000`000000b4
fffff880`09dfe928 fffff880`09dfeb60
fffff880`09dfe930 fffffa80`0e1f6af0
fffff880`09dfe938 fffffa80`0e1f6af0
fffff880`09dfe940 fffff880`09dfeb60
fffff880`09dfe948 fffff800`039afbc3 nt!NtSetInformationFile+0x91f
fffff880`09dfe950 00000000`000000b4
fffff880`09dfe958 fffff880`09dfeb60
fffff880`09dfe960 00000000`00000000
fffff880`09dfe968 fffffa80`097d5760
fffff880`09dfe970 00000000`746c6644
fffff880`09dfe978 fffff880`09dfe998
fffff880`09dfe980 00000000`00000000
6: kd> dps
fffff880`09dfe988 fffffa80`0e254b10
fffff880`09dfe990 fffffa80`0e1f0101
fffff880`09dfe998 fffffa80`0687a250
fffff880`09dfe9a0 fffff880`099a0100 nmlhssrv01!__security_cookie
fffff880`09dfe9a8 fffffa80`09a33890
fffff880`09dfe9b0 fffffa80`0e1f6af0
fffff880`09dfe9b8 fffffa80`09abdc50
fffff880`09dfe9c0 fffffa80`0e1f6f20
fffff880`09dfe9c8 00000000`1a35e2c8
fffff880`09dfe9d0 fffffa80`0687a2e8
fffff880`09dfe9d8 00000000`00000000
fffff880`09dfe9e0 00000000`00000000
fffff880`09dfe9e8 ffffffff`800005ec
fffff880`09dfe9f0 fffffa80`0687a250
fffff880`09dfe9f8 fffff880`0999d498 nmlhssrv01!FsFilterFastIoQueryStandardInfo [d:\bsod\source\001.[2012.03.02]rollback\2012.08.22before\2.src_networkcontrol\procmgmt_sev64\fsfilter\fastio.c @ 145]
fffff880`09dfea00 fffffa80`09abdc50

nmlhssrv01!FsFilterFastIoQueryStandardInfo

source code:
BOOLEAN FsFilterFastIoQueryStandardInfo(
__in PFILE_OBJECT FileObject,
__in BOOLEAN Wait,
__out PFILE_STANDARD_INFORMATION Buffer,
__out PIO_STATUS_BLOCK IoStatus,
__in PDEVICE_OBJECT DeviceObject
)
{
//
// Pass through logic for this type of Fast I/O
//

PDEVICE_OBJECT nextDeviceObject = ((PFSFILTER_DEVICE_EXTENSION)DeviceObject->DeviceExtension)->AttachedToDeviceObject;
PFAST_IO_DISPATCH fastIoDispatch = nextDeviceObject->DriverObject->FastIoDispatch;

if (VALID_FAST_IO_DISPATCH_HANDLER(fastIoDispatch, FastIoQueryStandardInfo))
{
return (fastIoDispatch->FastIoQueryStandardInfo)(
FileObject,
Wait,
Buffer,
IoStatus,
nextDeviceObject);
}

return FALSE;
}

Seems to be the cause of a blue screen here.

OSR_Community_User · November 16, 2012, 2:11am

> That’s curious. I wonder how many pieces of library code think 00000000

means invalid address. About a million lines of C code also go:

If (somePointer) {
… valid path
} else {
… invalid path
}

Sounds like they should say:

If (somePointer != INVALID_POINTER)…

Is there some specific value that is DEFINED to be an invalid address?
Like for uninitialized pointers?

Jan

By definition, an invalid address is any address which is not valid. In
the 4GB address space, this means several hundred million to a couple
billion values are “invalid addresses”. So how could there possibly be a
unique value?

In Win64, there are 2^64 possible addresses, and at most instances, you
would find there are probably 2^40 invalid pointer values.

What you are referring to here is the particular value NULL, which is 0.
The most common failure mode is attempting to work at a small offset
relative to 0, which is one reason the first 65536 locations are
pre-designated “invalid” so that any attempt to use the NULL pointer to
access any member of a structure will cause an error at the hardware
level. Note this is a statistical accident, in that if you have a
structure for which sizeof() > 65536, this trick will fail. But
structures this massive are so infrequent that the trick effectively
catches 100% of attempts to dereference the NULL pointer.

Why would you imagine that there is one unique value is used to designate
an “invalid address”? There are 4.2 billion possible addresses, nearly
all of which are invalid.

So what you are looking for is either a NULL pointer, or, if you want to
be fancy, any 16-bit offset relative to 0, which is why I said that a test
ASSERT(p < 0xFFFF) [proper casting left as AEFTR] would catch more errors.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel Lebedynskiy
Sent: Thursday, November 15, 2012 8:25 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

> In user space, addresses 00000000 to 0000FFFF do not exist.

That’s the case usually, but not always. On Windows versions prior to win8
user apps can allocate memory at NULL.

> You have a bug. You have to find and fix the bug. There is no
> alternative.

We are in agreement here.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Thursday, November 15, 2012 7:55 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do not
exist. In kernel mode, this is interpreted according to the active
mapping, which means that 00000000 to 0000FFFF do not exist. The fact
that they are interpreted in the lower section of memory (<2GB, <3GB, <8TB
depending on the OS configuration) doesn’t (a) change the fact that they
are invalid and (b) adding an exception handler will somehow magically
will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no
alternative.

When I had to do exception handling based on illegal addresses, it was
entirely due to hardware failure. The program, as far as we could tell,
was correct. But the hardware was experimental, and we had to keep
running in spite of defective hardware. But in this case, it is clear
that the driver is defective. So you have to fix it.
joe

> NULL is a user space address so technically you *can* handle access
> violations resulting from dereferencing a NULL pointer.
>
> The answer to whether you *should* be doing this is, of course, a big
> NO.

NTDEV is sponsored by OSR

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

NTDEV is sponsored by OSR

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 · November 16, 2012, 2:15am

>> In user space, addresses 00000000 to 0000FFFF do not exist.

That’s the case usually, but not always. On Windows versions prior to win8
user apps can allocate memory at NULL.

No. This was never possible. It was not possible in Win16 and it was
never possible in Win32. Several APIs critically depend on this behavior.

There is no possible way to allocate user memory at location 0. What is
your evidence that this could be done?

> You have a bug. You have to find and fix the bug. There is no
> alternative.

We are in agreement here.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Thursday, November 15, 2012 7:55 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do not
exist. In kernel mode, this is interpreted according to the active
mapping, which means that 00000000 to 0000FFFF do not exist. The fact
that they are interpreted in the lower section of memory (<2GB, <3GB, <8TB
depending on the OS configuration) doesn’t (a) change the fact that they
are invalid and (b) adding an exception handler will somehow magically
will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no
alternative.

When I had to do exception handling based on illegal addresses, it was
entirely due to hardware failure. The program, as far as we could tell,
was correct. But the hardware was experimental, and we had to keep
running in spite of defective hardware. But in this case, it is clear
that the driver is defective. So you have to fix it.
joe

> NULL is a user space address so technically you *can* handle access
> violations resulting from dereferencing a NULL pointer.
>
> The answer to whether you *should* be doing this is, of course, a big
> NO.

NTDEV is sponsored by OSR

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 · November 16, 2012, 2:42am

Where are the asserts for NULL pointers?
Is DeviceObject valid?
Is DeviceObject->DeviceExtension valid?
Is nextDeviceObject valid?
Is nextDeviceObject->DriverObject valid?
Is fastIoDispatch valid?
Is fastIoDispatch->FastIoQueryStandardInfo valid?
Are all of the other pointers valid?

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com [xxxxx@gmail.com]
Sent: 16 November 2012 06:52
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

Look at this…

source code:
BOOLEAN FsFilterFastIoQueryStandardInfo(
__in PFILE_OBJECT FileObject,
__in BOOLEAN Wait,
__out PFILE_STANDARD_INFORMATION Buffer,
__out PIO_STATUS_BLOCK IoStatus,
__in PDEVICE_OBJECT DeviceObject
)
{
//
// Pass through logic for this type of Fast I/O
//

PDEVICE_OBJECT nextDeviceObject = ((PFSFILTER_DEVICE_EXTENSION)DeviceObject->DeviceExtension)->AttachedToDeviceObject;
PFAST_IO_DISPATCH fastIoDispatch = nextDeviceObject->DriverObject->FastIoDispatch;

if (VALID_FAST_IO_DISPATCH_HANDLER(fastIoDispatch, FastIoQueryStandardInfo))
{
return (fastIoDispatch->FastIoQueryStandardInfo)(
FileObject,
Wait,
Buffer,
IoStatus,
nextDeviceObject);
}

return FALSE;
}

OSR_Community_User · November 16, 2012, 5:55am

I thought there was a defined bad pointer value, and some hunting finds it. MmBadPointer (http://msdn.microsoft.com/en-us/library/windows/hardware/ff554494(v=vs.85).aspx). It says “The MmBadPointer global variable is a pointer to a memory location that is guaranteed to be invalid.”

From what Pavel says (and I usually think of him as a pretty reliable source), the address 0 MIGHT be a valid address on pre Win8 systems. On a variety of embedded systems, 0 will also be a valid pointer value, like say real mode x86 code.

A variety of other values have defined invalid values, like NaN is a value guaranteed not to be a valid float, and INVALID_HANDLE_VALUE is guaranteed to not be a valid handle in Windows.

I see C# has the concept of a Nullable Type (http://msdn.microsoft.com/en-us/library/2cf62fcy.aspx) which is defined as “Nullable types can represent all the values of an underlying type, and an additional null value”.

I also see that C++11 has fixed this problem, by the introduction of nullptr, which is a unique type.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Thursday, November 15, 2012 11:11 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

That’s curious. I wonder how many pieces of library code think
00000000 means invalid address. About a million lines of C code also go:

If (somePointer) {
… valid path
} else {
… invalid path
}

Sounds like they should say:

If (somePointer != INVALID_POINTER)…

Is there some specific value that is DEFINED to be an invalid address?
Like for uninitialized pointers?

Jan

By definition, an invalid address is any address which is not valid. In the 4GB address space, this means several hundred million to a couple billion values are “invalid addresses”. So how could there possibly be a unique value?

In Win64, there are 2^64 possible addresses, and at most instances, you would find there are probably 2^40 invalid pointer values.

What you are referring to here is the particular value NULL, which is 0.
The most common failure mode is attempting to work at a small offset relative to 0, which is one reason the first 65536 locations are pre-designated “invalid” so that any attempt to use the NULL pointer to access any member of a structure will cause an error at the hardware
level. Note this is a statistical accident, in that if you have a
structure for which sizeof() > 65536, this trick will fail. But structures this massive are so infrequent that the trick effectively catches 100% of attempts to dereference the NULL pointer.

Why would you imagine that there is one unique value is used to designate an “invalid address”? There are 4.2 billion possible addresses, nearly all of which are invalid.

So what you are looking for is either a NULL pointer, or, if you want to be fancy, any 16-bit offset relative to 0, which is why I said that a test ASSERT(p < 0xFFFF) [proper casting left as AEFTR] would catch more errors.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel
Lebedynskiy
Sent: Thursday, November 15, 2012 8:25 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

> In user space, addresses 00000000 to 0000FFFF do not exist.

That’s the case usually, but not always. On Windows versions prior to
win8 user apps can allocate memory at NULL.

> You have a bug. You have to find and fix the bug. There is no
> alternative.

We are in agreement here.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Thursday, November 15, 2012 7:55 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do
not exist. In kernel mode, this is interpreted according to the
active mapping, which means that 00000000 to 0000FFFF do not exist.
The fact that they are interpreted in the lower section of memory
(<2GB, <3GB, <8TB depending on the OS configuration) doesn’t (a)
change the fact that they are invalid and (b) adding an exception
handler will somehow magically will make your defective driver “right”.

You have a bug. You have to find and fix the bug. There is no
alternative.

When I had to do exception handling based on illegal addresses, it was
entirely due to hardware failure. The program, as far as we could
tell, was correct. But the hardware was experimental, and we had to
keep running in spite of defective hardware. But in this case, it is
clear that the driver is defective. So you have to fix it.
joe

> NULL is a user space address so technically you *can* handle access
> violations resulting from dereferencing a NULL pointer.
>
> The answer to whether you *should* be doing this is, of course, a big
> NO.

NTDEV is sponsored by OSR

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

NTDEV is sponsored by OSR

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

NTDEV is sponsored by OSR

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

Maxim_S_Shatskih · November 16, 2012, 11:39am

>From what Pavel says (and I usually think of him as a pretty reliable source), the address 0 MIGHT be

a valid address on pre Win8 systems

C and C++ languages define (PVOID)0 to be different from any valid pointer.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · November 16, 2012, 11:41am

> I thought there was a defined bad pointer value, and some hunting finds

it. MmBadPointer
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff554494(v=vs.85).aspx).
It says “The MmBadPointer global variable is a pointer to a memory
location that is guaranteed to be invalid.”

No, it is /A/ pointer to /A/ location. Not the unique value of an invalid
pointer! So it could be one of several billion possible values, and might
even change from boot to boot. Comparing a pointer against this will
always return “not equal” for all practical purposes, meaning you think
you have a pointer that is valid when in fact you do not.

From what Pavel says (and I usually think of him as a pretty reliable
source), the address 0 MIGHT be a valid address on pre Win8 systems. On a
variety of embedded systems, 0 will also be a valid pointer value, like
say real mode x86 code.

No, the address 0 is ALWAYS an invalid address. On every Windows system
since the mid-1980s, since Windows 386, at least.

Why would you care about real mode x86 code if you are writing a Windows
driver?

A variety of other values have defined invalid values, like NaN is a value
guaranteed not to be a valid float, and INVALID_HANDLE_VALUE is guaranteed
to not be a valid handle in Windows.

and the variable you name is guaranteed to be one of the several hundred
million to several billion possible invalid addresses. NaN is a value
defined by the IEEE floating point standard, and should not be confused
with bad pointer values. You need to understand how mapped addresses are
resolved. If there is no entry in the page map, the address is invalid.
Period. That’s it. ANY of several billion values (or in Win64, several
trillion values) will be invalid if it does not have a mapping.

I see C# has the concept of a Nullable Type
(http://msdn.microsoft.com/en-us/library/2cf62fcy.aspx) which is defined
as “Nullable types can represent all the values of an underlying type, and
an additional null value”.

There is no equivalent to this in C or C++. When we start writing drivers
in C#, this will possibly make sense.

I also see that C++11 has fixed this problem, by the introduction of
nullptr, which is a unique type.

The problem was an ambiguity of the type of the number 0 with the type of
a pointer. Sometimes you would have to write an explicit cast to get
overload resolution to work properly:

void SomeFunc(whatever * p)
{
if (p == NULL) …

void SomeFunc(int n)
{
…

If you called SomeFunc(NULL), it would have an ambiguous resolution,
because the compiler would not know if you meant “0 the integer” or “0 the
NULL pointer” (since NULL is a #define and all lthe information is gone by
the time the compiler sees it). nullptr is a way to guarantee correct
resolution, so if you call SomeFunc(nullptr) it has an unambiguous
resolution.

It helps a lot if you understand the basic issues.

Joe Newcomer
[Former C++/MFC MVP]

Jan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Thursday, November 15, 2012 11:11 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)

> That’s curious. I wonder how many pieces of library code think
> 00000000 means invalid address. About a million lines of C code also go:
>
> If (somePointer) {
> … valid path
> } else {
> … invalid path
> }
>
> Sounds like they should say:
>
> If (somePointer != INVALID_POINTER)…
>
> Is there some specific value that is DEFINED to be an invalid address?
> Like for uninitialized pointers?
>
> Jan
>
By definition, an invalid address is any address which is not valid. In
the 4GB address space, this means several hundred million to a couple
billion values are “invalid addresses”. So how could there possibly be a
unique value?

In Win64, there are 2^64 possible addresses, and at most instances, you
would find there are probably 2^40 invalid pointer values.

What you are referring to here is the particular value NULL, which is 0.
The most common failure mode is attempting to work at a small offset
relative to 0, which is one reason the first 65536 locations are
pre-designated “invalid” so that any attempt to use the NULL pointer to
access any member of a structure will cause an error at the hardware
level. Note this is a statistical accident, in that if you have a
structure for which sizeof() > 65536, this trick will fail. But
structures this massive are so infrequent that the trick effectively
catches 100% of attempts to dereference the NULL pointer.

Why would you imagine that there is one unique value is used to designate
an “invalid address”? There are 4.2 billion possible addresses, nearly
all of which are invalid.

So what you are looking for is either a NULL pointer, or, if you want to
be fancy, any 16-bit offset relative to 0, which is why I said that a test
ASSERT(p < 0xFFFF) [proper casting left as AEFTR] would catch more errors.
joe
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel
> Lebedynskiy
> Sent: Thursday, November 15, 2012 8:25 PM
> To: Windows System Software Devs Interest List
> Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)
>
>> In user space, addresses 00000000 to 0000FFFF do not exist.
>
> That’s the case usually, but not always. On Windows versions prior to
> win8 user apps can allocate memory at NULL.
>
>> You have a bug. You have to find and fix the bug. There is no
>> alternative.
>
> We are in agreement here.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@flounder.com
> Sent: Thursday, November 15, 2012 7:55 PM
> To: Windows System Software Devs Interest List
> Subject: RE: RE:[ntdev] BSOD!!! (bugcheck 0x3b)
>
> No, 0 is an address. In user space, addresses 00000000 to 0000FFFF do
> not exist. In kernel mode, this is interpreted according to the
> active mapping, which means that 00000000 to 0000FFFF do not exist.
> The fact that they are interpreted in the lower section of memory
> (<2GB, <3GB, <8TB depending on the OS configuration) doesn’t (a)
> change the fact that they are invalid and (b) adding an exception
> handler will somehow magically will make your defective driver “right”.
>
> You have a bug. You have to find and fix the bug. There is no
> alternative.
>
> When I had to do exception handling based on illegal addresses, it was
> entirely due to hardware failure. The program, as far as we could
> tell, was correct. But the hardware was experimental, and we had to
> keep running in spite of defective hardware. But in this case, it is
> clear that the driver is defective. So you have to fix it.
> joe
>
>
>> NULL is a user space address so technically you *can* handle access
>> violations resulting from dereferencing a NULL pointer.
>>
>> The answer to whether you *should* be doing this is, of course, a big
>> NO.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

NTDEV is sponsored by OSR

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

NTDEV is sponsored by OSR

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