Bug Check 0xD1 in DPC routines

Hi,

I am developing a serial driver in which i have a couple of DPC functions (one for processing read requests and another one for write requests).

In case of read, DPC function copies the data from hardware to the driver buffer, if necessary copies the data to the application

buffer, unmarks the read request to be cancellable and completes the request.

In case of Write the DPC function writes the data to hardware (buffer if required) and if all the data requested by the WRite command has been written, then it completes the write request.

When testing the driver for higher baud rates, i am consistently getting crashes in this DPC function. I am getting crashes at different locations , not in a single location. Below is the output of “analyze -v” command for one such crash.

The analysis output says that i am accessing paged memory at DPC level. However i didn’t allocate any pageable memory anywhere in my code.

BugCheck D1, {c5c4c466, 2, 0, 8bc44261}
Probably caused by : PortDriver.sys ( PortDriver!WdfRequestUnmarkCancelable+20 )
Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
832b7840 cc int 3
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: c5c4c466, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8bc44261, address which referenced memory
Debugging Details:

READ_ADDRESS: c5c4c466
CURRENT_IRQL: 2
FAULTING_IP:
Wdf01000!FxIoQueue::RequestCancelable+e
8bc44261 80b9a400000000 cmp byte ptr [ecx+0A4h],0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: SerialValidati
TRAP_FRAME: 8078ae3c – (.trap 0xffffffff8078ae3c)
ErrCode = 00000000
eax=87e46290 ebx=8719f010 ecx=c5c4c3c2 edx=00000400 esi=87e46290 edi=781b9d68
eip=8bc44261 esp=8078aeb0 ebp=8078aebc iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
Wdf01000!FxIoQueue::RequestCancelable+0xe:
8bc44261 80b9a400000000 cmp byte ptr [ecx+0A4h],0 ds:0023:c5c4c466=??
Resetting default scope
LAST_CONTROL_TRANSFER: from 8331bffb to 832b7840
STACK_TEXT:
8078aa04 8331bffb 00000003 a2f9e648 00000065 nt!RtlpBreakWithStatusInstruction
8078aa54 8331caf9 00000003 c5c4c466 8bc44261 nt!KiBugCheckDebugBreak+0x1c
8078ae1c 8327dcdb 0000000a c5c4c466 00000002 nt!KeBugCheck2+0x68b
8078ae1c 8bc44261 0000000a c5c4c466 00000002 nt!KiTrap0E+0x2cf
8078aebc 8bc4cc29 8719f010 00000000 00000000 Wdf01000!FxIoQueue::RequestCancelable+0xe
8078aee8 917c4d60 87180ea0 87e46290 8078af24 Wdf01000!imp_WdfRequestUnmarkCancelable+0xab
8078aef8 917c8c28 781b9d68 00000000 c0000001 PortDriver!WdfRequestUnmarkCancelable+0x20 [c:\program files\windows kits\8.0\include\wdf\kmdf\1.11\wdfrequest.h @ 780]
8078af24 8bc81c40 78e608e8 8336a600 8719f748 PortDriver!PortWriteCompleteDPC+0x368 [d:\08-09-2014\08-09-2014\08-09-2014\dpc.c @ 339]
8078af40 8bc81c57 8078afa4 832b4935 8719f748 Wdf01000!FxDpc::DpcHandler+0x9b
8078af48 832b4935 8719f748 8719f710 00000000 Wdf01000!FxDpc::FxDpcThunk+0xd
8078afa4 832b4798 83368d20 8818ed48 00000000 nt!KiExecuteAllDpcs+0xf9
8078aff4 832b3f5c ad01fbe4 00000000 00000000 nt!KiRetireDpcList+0xd5
8078aff8 ad01fbe4 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
WARNING: Frame IP not in any known module. Following frames may be wrong.
832b3f5c 00000000 0000001a 00d6850f bb830000 0xad01fbe4
STACK_COMMAND: kb
FOLLOWUP_IP:
PortDriver!WdfRequestUnmarkCancelable+20 [c:\program files\windows kits\8.0\include\wdf\kmdf\1.11\wdfrequest.h @ 780]
917c4d60 5d pop ebp
FAULTING_SOURCE_CODE:
776: WDFREQUEST Request
777: )
778: {
779: return ((PFN_WDFREQUESTUNMARKCANCELABLE) WdfFunctions[WdfRequestUnmarkCancelableTableIndex])(WdfDriverGlobals, Request);

780: }
781:
782: //
783: // WDF Function: WdfRequestIsCanceled
784: //
785: typedef
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: PortDriver!WdfRequestUnmarkCancelable+20
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: PortDriver
IMAGE_NAME: PortDriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 542a97e1
FAILURE_BUCKET_ID: 0xD1_PortDriver!WdfRequestUnmarkCancelable+20
BUCKET_ID: 0xD1_PortDriver!WdfRequestUnmarkCancelable+20
Followup: MachineOwner


0: kd> .trap 0xffffffff8078ae3c
ErrCode = 00000000
eax=87e46290 ebx=8719f010 ecx=c5c4c3c2 edx=00000400 esi=87e46290 edi=781b9d68
eip=8bc44261 esp=8078aeb0 ebp=8078aebc iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
Wdf01000!FxIoQueue::RequestCancelable+0xe:
8bc44261 80b9a400000000 cmp byte ptr [ecx+0A4h],0 ds:0023:c5c4c466=??

Below is the some of code in my write DPC.

// WdfSpinLockAcquire(pstDeviceContext->hPortSpinLock);
hRequest = pstDeviceContext->hCurrentWriteRequest;
…// Some code to write the data to hardware buffer if necessary
pstRequestContext->ulBytesNeedtoTransmit -= ulBytesTransmitting;
//Completing the Write Request
if(!pstRequestContext->ulBytesNeedtoTransmit)
{

lStatus = WdfRequestUnmarkCancelable(hRequest);

if(lStatus != STATUS_CANCELLED)
{
pstDeviceContext->hCurrentWriteRequest = NULL;
bIsSpinLockReleased = TRUE;
WdfSpinLockRelease(pstDeviceContext->hPortSpinLock);
WdfRequestCompleteWithInformation(hRequest, STATUS_SUCCESS,(ULONG_PTR)pstRequestContext->ulLength);
}
else
{
bIsSpinLockReleased = TRUE;
WdfSpinLockRelease(pstDeviceContext->hPortSpinLock);
}
}

I have used PAGED_CODE() macro for the functions in my code that creates DPC objects. The DPC objects themselves are present in non paged pool though. I am using the macro WdfObjectGet_DEVICE_CONTEXT for retrieving the device context space.

WHen i am not creating any paged memory at all why do i still see these errors related to page faults at higher IRQL levels?

On Tue, Sep 30, 2014 at 12:01 PM, wrote:

> c5c4c466

1. your dpc routines should not use PAGED_CODE.
2. c5c4c466 is a garbage address - your hRequest is likely not valid.
3. turn verifier on for your driver.
4. what is the output from !wdfkd.wdflogdump?
5. You need to handle the other failure cases from
WdfRequestUnmarkCancelable.
6. Note also the Remarks section for this function, where the cancel race
condition re-appears, unresolved by the framework :-(.

Mark Roddy

xxxxx@gmail.com wrote:

I am developing a serial driver in which i have a couple of DPC functions (one for processing read requests and another one for write requests).

In case of read, DPC function copies the data from hardware to the driver buffer, if necessary copies the data to the application

buffer, unmarks the read request to be cancellable and completes the request.

In case of Write the DPC function writes the data to hardware (buffer if required) and if all the data requested by the WRite command has been written, then it completes the write request.

When testing the driver for higher baud rates, i am consistently getting crashes in this DPC function. I am getting crashes at different locations , not in a single location. Below is the output of “analyze -v” command for one such crash.

The analysis output says that i am accessing paged memory at DPC level. However i didn’t allocate any pageable memory anywhere in my code.

ErrCode = 00000000
eax=87e46290 ebx=8719f010 ecx=c5c4c3c2 edx=00000400 esi=87e46290 edi=781b9d68
eip=8bc44261 esp=8078aeb0 ebp=8078aebc iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
Wdf01000!FxIoQueue::RequestCancelable+0xe:
8bc44261 80b9a400000000 cmp byte ptr [ecx+0A4h],0 ds:0023:c5c4c466=??

Look at the address it is using: c5c4c3c2. That is not a legitimate
address. You have overwritten the end of a buffer somewhere and wiped
out your WDFREQUEST. (This would correspond to a WDFREQUEST of
0x3B3C3D3E).


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

> An attempt was made to access a pageable (or completely invalid) address at an interrupt request level that was too high …

C5C4C466 is a non-paged system VA. So it is completely invalid. Because the thread is running at DPC level, you get a D1 bugcheck. At a lower IRQL you would have bugcheck 50 (PAGE_FAULT_IN_NON_PAGED_AREA).

In my driver, when ever i process a request, I am declaring a local variable of type WDFREQUEST and loading the currently active request object from a variable in my device context . All the statements
right from loading the WDFREQUEST object to the statement just before WdfRequestComplete function, are in spin lock in all cases. So i am hoping that there is no syncrhonization issue here.

how else can my WDFREQUEST object become invalid?
Tim,

Could you please give an example how a buffer overwriting can affect my WDFREQUEST object?

Where else do you potentially complete the request?? Do you have a canceled on queue callback? Have you turned on verifier?

d

Bent from my phone


From: xxxxx@gmail.commailto:xxxxx
Sent: ?10/?1/?2014 8:19 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Bug Check 0xD1 in DPC routines

In my driver, when ever i process a request, I am declaring a local variable of type WDFREQUEST and loading the currently active request object from a variable in my device context . All the statements
right from loading the WDFREQUEST object to the statement just before WdfRequestComplete function, are in spin lock in all cases. So i am hoping that there is no syncrhonization issue here.

how else can my WDFREQUEST object become invalid?
Tim,

Could you please give an example how a buffer overwriting can affect my WDFREQUEST object?


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>

i complete the request at three places.

  1. If i have enough data in driver to satisfy the current request, In my dispatch function, ,
  • After i finish copying the data to the user buffer, i release the spin lock and finish the request.
  1. In Cancel routine, i cancel the request.

  2. If i don’t have enough data to complete the current request, I wait till i gather data from interrupts and queue a DPC. In my DPC routine i complete the request.

  3. In some error scenarios. I will check these scenarios once again to make sure i am cleaning up the shared variables properly before completing the requests.

In all of these cases, i am holding heavy spin locks and guarding the variables in devicecontext. Hence i am doubting if this could be a synchronization issue.

Moreover recently i saw a crash where the function WdfDPCEnqueue(DPC) was also giving a crash. This function is called in the ISR.

This is making me doubt that there is something fundamentally wrong in creating the DPC objects or allocating memory in my driver. I reviewed the code but i am not creating paged memory anywhere. I have even removed all the PAGED_CODE() macros and #pragma Alloc_text (PAGE) sections from my driver.

I was not running Driver verifier at the time of these crashes. I will run and see the result once again.

But any hints from the above? If you like to see any specific part of my code, please let me know. I will be glad to post the code.

xxxxx@gmail.com wrote:

In my driver, when ever i process a request, I am declaring a local variable of type WDFREQUEST and loading the currently active request object from a variable in my device context . All the statements
right from loading the WDFREQUEST object to the statement just before WdfRequestComplete function, are in spin lock in all cases. So i am hoping that there is no syncrhonization issue here.

how else can my WDFREQUEST object become invalid?
Tim,

Could you please give an example how a buffer overwriting can affect my WDFREQUEST object?

I’m not saying the object became invalid. I’m saying your handle is
bad. A WDFREQUEST just an integer that indirectly points to a
structure. If your device context had this, for example:

unsigned char MyBuffer[128];
WDFREQUEST PendingRequest;

And you wrote 140 bytes into MyBuffer, that would trash the
PendingRequests handle.


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

Tim,

I reviewed my code in DPC and read requests where i am declaring the WDFREQUEST Object but i am not doing anything that could possibly corrupt the value of hRequest object.

I am getting so many other types of crashes as well… Below is the output of another kind of crash.

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f1f0f0b2, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8bc0da8a, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)

Debugging Details:

READ_ADDRESS: f1f0f0b2

FAULTING_IP:
Wdf01000!FxDevice::Dispatch+1d
8bc0da8a 8b3b mov edi,dword ptr [ebx]

MM_INTERNAL_CODE: 2

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5010ac41

MODULE_NAME: Wdf01000

FAULTING_MODULE: 8bc0a000 Wdf01000

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x50

PROCESS_NAME: SerialValidati

CURRENT_IRQL: 2

TRAP_FRAME: ae10ba88 – (.trap 0xffffffffae10ba88)
ErrCode = 00000000
eax=874314a8 ebx=f1f0f0b2 ecx=87432958 edx=f1f0efee esi=864ecf00 edi=874328a0
eip=8bc0da8a esp=ae10bafc ebp=ae10bb18 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
Wdf01000!FxDevice::Dispatch+0x1d:
8bc0da8a 8b3b mov edi,dword ptr [ebx] ds:0023:f1f0f0b2=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 832e2ffb to 8327e840

STACK_TEXT:
ae10b5dc 832e2ffb 00000003 8cac8530 00000065 nt!RtlpBreakWithStatusInstruction
ae10b62c 832e3af9 00000003 c0603c78 f1f0f0b2 nt!KiBugCheckDebugBreak+0x1c
ae10b9f0 83291b3f 00000050 f1f0f0b2 00000000 nt!KeBugCheck2+0x68b
ae10ba70 83244ae8 00000000 f1f0f0b2 00000000 nt!MmAccessFault+0x106
ae10ba70 8bc0da8a 00000000 f1f0f0b2 00000000 nt!KiTrap0E+0xdc
ae10bb18 8bc0da33 874328a0 864ecf00 87261288 Wdf01000!FxDevice::Dispatch+0x1d
ae10bb34 8323ac29 874328a0 864ecf00 864ecf00 Wdf01000!FxDevice::DispatchWithLock+0x77
ae10bb4c 8342fb29 87261288 864ecf00 864ecf94 nt!IofCallDriver+0x63
ae10bb6c 83475860 874328a0 87261288 00000001 nt!IopSynchronousServiceTail+0x1f8
ae10bc08 832418fa 874328a0 0000002c 00000000 nt!NtWriteFile+0x6e8
ae10bc08 77317094 874328a0 0000002c 00000000 nt!KiFastCallEntry+0x12a
005cf764 77316a74 756d96a1 0000001c 0000002c ntdll!KiFastSystemCallRet
005cf768 756d96a1 0000001c 0000002c 00000000 ntdll!ZwWriteFile+0xc
005cf7cc 75c7543c 0000001c 039e05c0 0000000a KERNELBASE!WriteFile+0xaa
005cf7e8 011c3abf 0000001c 039e05c0 0000000a kernel32!WriteFileImplementation+0x76
005cfd60 011c30d5 0000001c 005cfe54 0000000a SerialValidation20!send_packets+0x16f [d:\24-09-2014\solution_amat\solution_amat\solution_amat\serialvalidation.cpp @ 424]
005cfe78 75c6ed6c 039e0508 005cfec4 7733377b SerialValidation20!comm_write_thread_proc+0x95 [d:\24-09-2014\solution_amat\solution_amat\solution_amat\serialvalidation.cpp @ 534]
005cfe84 7733377b 039e0508 7767a789 00000000 kernel32!BaseThreadInitThunk+0xe
005cfec4 7733374e 011c3040 039e0508 00000000 ntdll!__RtlUserThreadStart+0x70
005cfedc 00000000 011c3040 039e0508 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxDevice::Dispatch+1d
8bc0da8a 8b3b mov edi,dword ptr [ebx]

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: Wdf01000!FxDevice::Dispatch+1d

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0x50_Wdf01000!FxDevice::Dispatch+1d

BUCKET_ID: 0x50_Wdf01000!FxDevice::Dispatch+1d

Followup: MachineOwner

To answer Mark’s questions,

  1. your dpc routines should not use PAGED_CODE.
    My dirver is not using PAGED_CODE macros.

  2. c5c4c466 is a garbage address - your hRequest is likely not valid.

I checked my code but i couldn’t see how the hRequest object can get overwritten at all…i not doing any memory movement operations on local stack memory or any other operation that could corrupt this variable.

  1. turn verifier on for your driver.

I turned on verifier but it is not catching any of the exceptions.
4. what is the output from !wdfkd.wdflogdump?
wdfkd.wdflogdump is not displaying proper output …My symbols are all fine. I am trying to understand what is the problem with this.

  1. You need to handle the other failure cases from
    WdfRequestUnmarkCancelable.

I have added modified my code to complete teh request only if WdfRequestUnmarkCancelable returns success and to generated an assert in all other cases.

None of these crashes are pointing to my driver and it really pisses me off… I was trying to read these stack traces and analyzing the assembly code but i soon digress into thinking what is the use if i can’t relate the crash to my driver?

One common point of all these crashes is that these crashes are occuring when the framework is trying to dispatch the request to the driver.

Can somebody please suggest what portion of my driver could cause this mess? I am sitting on this for days together but really not making any progress…

There are still bad symbols for Wdf being served up for version 9 and the
symptoms are that wdflogdump, and other wdfkd commands don’t work. Problem
goes away if you move to v 11. Or you can search this list and learn how to
get the functional symbols for wdf. You are most likely stomping on your
own data structures. Verifier won’t help much with that. Runtime logging
and structure verification debug code can help. All of these crashes are
pointing at your driver. “New code is crappy code” is one of the primary
rules of software engineering.

Mark Roddy

On Mon, Oct 6, 2014 at 10:27 AM, wrote:

> Tim,
>
> I reviewed my code in DPC and read requests where i am declaring the
> WDFREQUEST Object but i am not doing anything that could possibly corrupt
> the value of hRequest object.
>
> I am getting so many other types of crashes as well… Below is the output
> of another kind of crash.
>
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>

>
> PAGE_FAULT_IN_NONPAGED_AREA (50)
> Invalid system memory was referenced. This cannot be protected by
> try-except,
> it must be protected by a Probe. Typically the address is just plain bad
> or it
> is pointing at freed memory.
> Arguments:
> Arg1: f1f0f0b2, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: 8bc0da8a, If non-zero, the instruction address which referenced the
> bad memory
> address.
> Arg4: 00000002, (reserved)
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: f1f0f0b2
>
> FAULTING_IP:
> Wdf01000!FxDevice::Dispatch+1d
> 8bc0da8a 8b3b mov edi,dword ptr [ebx]
>
> MM_INTERNAL_CODE: 2
>
> IMAGE_NAME: Wdf01000.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 5010ac41
>
> MODULE_NAME: Wdf01000
>
> FAULTING_MODULE: 8bc0a000 Wdf01000
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0x50
>
> PROCESS_NAME: SerialValidati
>
> CURRENT_IRQL: 2
>
> TRAP_FRAME: ae10ba88 – (.trap 0xffffffffae10ba88)
> ErrCode = 00000000
> eax=874314a8 ebx=f1f0f0b2 ecx=87432958 edx=f1f0efee esi=864ecf00
> edi=874328a0
> eip=8bc0da8a esp=ae10bafc ebp=ae10bb18 iopl=0 nv up ei ng nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010282
> Wdf01000!FxDevice::Dispatch+0x1d:
> 8bc0da8a 8b3b mov edi,dword ptr [ebx]
> ds:0023:f1f0f0b2=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 832e2ffb to 8327e840
>
> STACK_TEXT:
> ae10b5dc 832e2ffb 00000003 8cac8530 00000065
> nt!RtlpBreakWithStatusInstruction
> ae10b62c 832e3af9 00000003 c0603c78 f1f0f0b2 nt!KiBugCheckDebugBreak+0x1c
> ae10b9f0 83291b3f 00000050 f1f0f0b2 00000000 nt!KeBugCheck2+0x68b
> ae10ba70 83244ae8 00000000 f1f0f0b2 00000000 nt!MmAccessFault+0x106
> ae10ba70 8bc0da8a 00000000 f1f0f0b2 00000000 nt!KiTrap0E+0xdc
> ae10bb18 8bc0da33 874328a0 864ecf00 87261288
> Wdf01000!FxDevice::Dispatch+0x1d
> ae10bb34 8323ac29 874328a0 864ecf00 864ecf00
> Wdf01000!FxDevice::DispatchWithLock+0x77
> ae10bb4c 8342fb29 87261288 864ecf00 864ecf94 nt!IofCallDriver+0x63
> ae10bb6c 83475860 874328a0 87261288 00000001
> nt!IopSynchronousServiceTail+0x1f8
> ae10bc08 832418fa 874328a0 0000002c 00000000 nt!NtWriteFile+0x6e8
> ae10bc08 77317094 874328a0 0000002c 00000000 nt!KiFastCallEntry+0x12a
> 005cf764 77316a74 756d96a1 0000001c 0000002c ntdll!KiFastSystemCallRet
> 005cf768 756d96a1 0000001c 0000002c 00000000 ntdll!ZwWriteFile+0xc
> 005cf7cc 75c7543c 0000001c 039e05c0 0000000a KERNELBASE!WriteFile+0xaa
> 005cf7e8 011c3abf 0000001c 039e05c0 0000000a
> kernel32!WriteFileImplementation+0x76
> 005cfd60 011c30d5 0000001c 005cfe54 0000000a
> SerialValidation20!send_packets+0x16f
> [d:\24-09-2014\solution_amat\solution_amat\solution_amat\serialvalidation.cpp
> @ 424]
> 005cfe78 75c6ed6c 039e0508 005cfec4 7733377b
> SerialValidation20!comm_write_thread_proc+0x95
> [d:\24-09-2014\solution_amat\solution_amat\solution_amat\serialvalidation.cpp
> @ 534]
> 005cfe84 7733377b 039e0508 7767a789 00000000
> kernel32!BaseThreadInitThunk+0xe
> 005cfec4 7733374e 011c3040 039e0508 00000000
> ntdll!__RtlUserThreadStart+0x70
> 005cfedc 00000000 011c3040 039e0508 00000000 ntdll!_RtlUserThreadStart+0x1b
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> Wdf01000!FxDevice::Dispatch+1d
> 8bc0da8a 8b3b mov edi,dword ptr [ebx]
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: Wdf01000!FxDevice::Dispatch+1d
>
> FOLLOWUP_NAME: MachineOwner
>
> FAILURE_BUCKET_ID: 0x50_Wdf01000!FxDevice::Dispatch+1d
>
> BUCKET_ID: 0x50_Wdf01000!FxDevice::Dispatch+1d
>
> Followup: MachineOwner
> ---------
>
> To answer Mark’s questions,
> 1. your dpc routines should not use PAGED_CODE.
> My dirver is not using PAGED_CODE macros.
>
> 2. c5c4c466 is a garbage address - your hRequest is likely not valid.
>
> I checked my code but i couldn’t see how the hRequest object can get
> overwritten at all…i not doing any memory movement operations on local
> stack memory or any other operation that could corrupt this variable.
>
> 3. turn verifier on for your driver.
>
> I turned on verifier but it is not catching any of the exceptions.
> 4. what is the output from !wdfkd.wdflogdump?
> wdfkd.wdflogdump is not displaying proper output …My symbols are all
> fine. I am trying to understand what is the problem with this.
>
> 5. You need to handle the other failure cases from
> WdfRequestUnmarkCancelable.
>
> I have added modified my code to complete teh request only if
> WdfRequestUnmarkCancelable returns success and to generated an assert in
> all other cases.
>
>
> None of these crashes are pointing to my driver and it really pisses me
> off… I was trying to read these stack traces and analyzing the assembly
> code but i soon digress into thinking what is the use if i can’t relate the
> crash to my driver?
>
> One common point of all these crashes is that these crashes are occuring
> when the framework is trying to dispatch the request to the driver.
>
>
> Can somebody please suggest what portion of my driver could cause this
> mess? I am sitting on this for days together but really not making any
> progress…
>
>
>
>
> —
> 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
>

xxxxx@gmail.com wrote:

I reviewed my code in DPC and read requests where i am declaring the WDFREQUEST Object but i am not doing anything that could possibly corrupt the value of hRequest object.

I am getting so many other types of crashes as well… Below is the output of another kind of crash.

It’s the same fundamental cause.

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f1f0f0b2, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8bc0da8a, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)

Look at the memory address referenced. That’s an offset from F1F0EFEE.
I guarantee you, you are overwriting a structure somewhere.

I’ll wager that your test data consists of a set of increment bytes: 00
01 02 03 04, etc. BOTH of the dumps you have sent us show that part of
that data has been written to a system data structure.

None of these crashes are pointing to my driver and it really pisses me off… I was trying to read these stack traces and analyzing the assembly code but i soon digress into thinking what is the use if i can’t relate the crash to my driver?

One common point of all these crashes is that these crashes are occuring when the framework is trying to dispatch the request to the driver.

Can somebody please suggest what portion of my driver could cause this mess? I am sitting on this for days together but really not making any progress…

First, verify for us that your test data consists of an incrementing
byte stream. Once you have done that, then you need to locate every
place in your code that you copy that data stream. Are you validating
the buffer lengths you are given? Are you making sure the Information
value you set in the requests isn’t larger than the output buffer?


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

Tim,

You are absolutely right… My test data DOES consist of incrementing data bytes.

Thanks a ton for giving a direction to me…I will start investigating the places where the data is getting copied and where the request is getting completed.