Web Cam Upfilter driver BSOD

Dear all
There is a BSOD on our Web Cam filter driver when runing DTM 1.4 for Windows 7 common scenario stress test. The BSOD analyze result is as the following. It seems to be that application call createfile, after my driver complete the create IRP, BSOD appeared. In my CREATE dispatch rotuine, I do nothing other than complete it with STATUS_SUCCESS. Does anyone give some advice?
thank you very much.

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 0d7b3b9a, The address that the exception occurred at
Arg3: 9b1b69ac, Trap Frame
Arg4: 00000000

Debugging Details:

PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
+57e3952f034ad824
0d7b3b9a ?? ???

TRAP_FRAME: 9b1b69ac – (.trap 0xffffffff9b1b69ac)
ErrCode = 00000010
eax=00000001 ebx=00000000 ecx=858210ff edx=0000007f esi=85821000 edi=85822837
eip=0d7b3b9a esp=9b1b6a20 ebp=9b1b6a64 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
0d7b3b9a ?? ???
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: TWebCamera.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 82ef8372 to 82f17d10

STACK_TEXT:
9b1b6514 82ef8372 0000008e c0000005 0d7b3b9a nt!KeBugCheckEx+0x1e
9b1b693c 82e7f016 9b1b6958 00000000 9b1b69ac nt!KiDispatchException+0x1ac
9b1b69a4 82e7efca 9b1b6a64 0d7b3b9a badb0d00 nt!CommonDispatchException+0x4a
9b1b6a1c 82ea3b33 00000001 85821000 00000000 nt!Kei386EoiHelper+0x192
9b1b6a64 949af2a4 873e13b8 9b1b6a88 82e774bc nt!IopfCompleteRequest+0x128
9b1b6a70 82e774bc 873e13b8 85821000 87285914 pgeffect!PGFilter_DispatchIo+0x3c [d:\hjiang\vss\vss75\pangu\source\driver\pgdriver\camera.c @ 2578]
9b1b6a88 8307b62d bfd6bf7c 9b1b6c30 00000000 nt!IofCallDriver+0x63
9b1b6b60 8305c1d7 873e13b8 a54a7a00 867147f0 nt!IopParseDevice+0xed7
9b1b6bdc 8308224d 00000000 9b1b6c30 00000040 nt!ObpLookupObjectName+0x4fa
9b1b6c38 8307a5ab 0012ecec 854a7a00 00000001 nt!ObOpenObjectByName+0x159
9b1b6cb4 83085eb6 0012ed48 c0100080 0012ecec nt!IopCreateFile+0x673
9b1b6d00 82e7e42a 0012ed48 c0100080 0012ecec nt!NtCreateFile+0x34
9b1b6d00 770264f4 0012ed48 c0100080 0012ecec nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012ed50 00000000 00000000 00000000 00000000 0x770264f4

STACK_COMMAND: kb

FOLLOWUP_IP:
pgeffect!PGFilter_DispatchIo+3c [d:\hjiang\vss\vss75\pangu\source\driver\pgdriver\camera.c @ 2578]
949af2a4 8bc6 mov eax,esi

FAULTING_SOURCE_CODE:
2574: //ASSERTMSG(FALSE, “Requests being sent to a dead device\n”);
2575: status = STATUS_DEVICE_REMOVED;
2576: }
2577:

2578: Irp->IoStatus.Status = status;
2579: IoCompleteRequest (Irp, IO_NO_INCREMENT);
2580:
2581: //DnydReleaseRemoveLock(&pDevExt->RemoveLock, Irp);
2582:
2583: return status;

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: pgeffect!PGFilter_DispatchIo+3c

FOLLOWUP_NAME: MachineOwner

Is it persisting error?
Are your driver is the lowest in the stack?
It is good idea to run the Driver Verifier.

Igor Sharovar

xxxxx@gmail.com wrote:

There is a BSOD on our Web Cam filter driver when runing DTM 1.4 for Windows 7 common scenario stress test. The BSOD analyze result is as the following. It seems to be that application call createfile, after my driver complete the create IRP, BSOD appeared. In my CREATE dispatch rotuine, I do nothing other than complete it with STATUS_SUCCESS. Does anyone give some advice?

TRAP_FRAME: 9b1b69ac – (.trap 0xffffffff9b1b69ac)
ErrCode = 00000010
eax=00000001 ebx=00000000 ecx=858210ff edx=0000007f esi=85821000 edi=85822837
eip=0d7b3b9a esp=9b1b6a20 ebp=9b1b6a64 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
0d7b3b9a ?? ???
Resetting default scope

STACK_TEXT:
9b1b6514 82ef8372 0000008e c0000005 0d7b3b9a nt!KeBugCheckEx+0x1e
9b1b693c 82e7f016 9b1b6958 00000000 9b1b69ac nt!KiDispatchException+0x1ac
9b1b69a4 82e7efca 9b1b6a64 0d7b3b9a badb0d00 nt!CommonDispatchException+0x4a
9b1b6a1c 82ea3b33 00000001 85821000 00000000 nt!Kei386EoiHelper+0x192
9b1b6a64 949af2a4 873e13b8 9b1b6a88 82e774bc nt!IopfCompleteRequest+0x128
9b1b6a70 82e774bc 873e13b8 85821000 87285914 pgeffect!PGFilter_DispatchIo+0x3c [d:\hjiang\vss\vss75\pangu\source\driver\pgdriver\camera.c @ 2578]

Based on the call stack, it looks like you completed the IRP while the
IRP completion routine address was garbage. Did you set a completion
routine in the IRP? Can you show the rest of the code in your
DispatchIo routine?

Perhaps a better question is why you are completing an IRP_MJ_CREATE IRP
at all in a filter driver. That’s an unusual thing to do. Normally,
you would just pass the IRP down without further comment.


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

Dear Tim Roberts

Dear tim
thank you very much.

  1. There is no complete routine. And there is no rest code, I just return STATUS_SUCESS.
  2. Because this is a control device object, I don’t want the CREATE object to be sent down the stack. So I just always complete this IRP with SUCESS.

THANKS again.

xxxxx@gmail.com wrote:

thank you very much.

  1. There is no complete routine. And there is no rest code, I just return STATUS_SUCESS.

There IS other code. We only see 3 or 4 lines of code in the dump
analysis, but the other evidence suggests that part of the IRP’s stack
has been trashed. This could happen in several ways, but without seeing
the code, we’re just shooting in the dark.

  1. Because this is a control device object, I don’t want the CREATE object to be sent down the stack. So I just always complete this IRP with SUCESS.

Ah, so you are a filter driver with a control DO? Remember, in that
case, that you are going to see IRP_MJ_CREATE requests for your control
DO, plus IRP_MJ_CREATE requests for the device you are filtering. THOSE
definitely need to be passed down the stack.


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

Dear Tim
thank you very much
The following is IRP_MJ_CREATE dispatch routine code. I will check if this IRP is for device object or control object, I will pass it down if it is a device object IRP.
This issue is only appeared when running WLK1.4 on Windows 7. Windows XP and Vista is ok.
I just think if it is because I build it on wdk7600–xp free build environment. Do you think if I need to build it on WDK 7600 -Windows 7 free build environment?

thanks again
Jiang huaping

NTSTATUS
PGFilter_DispatchIo(
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{
PIO_STACK_LOCATION pIrpStack;
NTSTATUS status;
PCONTROL_DEVICE_EXTENSION pCtrlExt;
PDEVICE_EXTENSION pDevExt;
//PCOMMON_DEVICE_DATA commonData;

PAGED_CODE();

//commonData = (PCOMMON_DEVICE_DATA)DeviceObject->DeviceExtension;
pCtrlExt = (PCONTROL_DEVICE_EXTENSION)DeviceObject->DeviceExtension;

if(!pCtrlExt->IsCtrlDevice)
{

return PGFilter_Pass(DeviceObject, Irp);
}

if (!pCtrlExt->Deleted)
{ //if not deleted
status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
pIrpStack = IoGetCurrentIrpStackLocation (Irp);

switch (pIrpStack->MajorFunction)
{
case IRP_MJ_CREATE:

pDevExt = (PDEVICE_EXTENSION)pCtrlExt->PairentObject->DeviceExtension;

if(PowerDeviceD0!=pDevExt->DevicePowerState)
{
//status = STATUS_DEVICE_POWERED_OFF;//STATUS_UNSUCCESSFUL;
}
//modify end.
DebugPrint((AREA_DEVICEIO,ERROR_LEVEL,“IRP_MJ_CREATE deviceobject=%x\n”,DeviceObject));
break;

case IRP_MJ_CLOSE:
//DP_TRACE0(“IRP_MJ_CLOSE \n”);
DebugPrint((AREA_READ,TRACE_LEVEL,“IRP_MJ_CLOSE \n”));
break;

case IRP_MJ_CLEANUP:
//DP_TRACE0(“IRP_MJ_CLEANUP \n”);
DebugPrint((AREA_READ,TRACE_LEVEL,“IRP_MJ_CLEANUP \n”));
break;

default:
break;
}
}
else
{
status = STATUS_DEVICE_REMOVED;
}

Irp->IoStatus.Status = status;
IoCompleteRequest (Irp, IO_NO_INCREMENT);

return status;
}

xxxxx@gmail.com wrote:

thank you very much
The following is IRP_MJ_CREATE dispatch routine code. I will check if this IRP is for device object or control object, I will pass it down if it is a device object IRP.

NTSTATUS
PGFilter_DispatchIo(
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{
PIO_STACK_LOCATION pIrpStack;
NTSTATUS status;
PCONTROL_DEVICE_EXTENSION pCtrlExt;
PDEVICE_EXTENSION pDevExt;
//PCOMMON_DEVICE_DATA commonData;

PAGED_CODE();

//commonData = (PCOMMON_DEVICE_DATA)DeviceObject->DeviceExtension;
pCtrlExt = (PCONTROL_DEVICE_EXTENSION)DeviceObject->DeviceExtension;

if(!pCtrlExt->IsCtrlDevice)
{
return PGFilter_Pass(DeviceObject, Irp);
}

Do you see the assumption in this code? You are checking IsCtrlDevice
in the CONTROL_DEVICE_EXTENSION, but if this is a request for your
filter DO, it won’t have CONTROL_DEVICE_EXTENSION. It will have some
other extension.

In the samples, they are very careful to make sure that the filter DO
and the control DO extensions both start exactly the same. That’s why
you have the COMMON_DEVICE_DATA concept. Have you done that? Can you
post BOTH of your extension structures?


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

Dear Tim
thank you very much.
Yes, there is a common member (IsCtrlDevice) in these two extension to see if it is a control object or device object. Please see the following code.

typedef struct _CONTROL_DEVICE_EXTENSION {
BOOLEAN IsCtrlDevice; // TRUE
PDEVICE_OBJECT PairentObject;
ULONG Deleted;
BOOLEAN IsAppHooking;
KSPIN_LOCK TCamSpinLock;
} CONTROL_DEVICE_EXTENSION, *PCONTROL_DEVICE_EXTENSION;

typedef struct _DEVICE_EXTENSION {
BOOLEAN IsCtrlDevice; // FALSE
PDEVICE_OBJECT Self;
PDEVICE_OBJECT PhysicalObj;
PDEVICE_OBJECT NextLowerDriver;
DEVICE_PNP_STATE DevicePnPState;
DEVICE_PNP_STATE PreviousPnPState;
PDEVICE_OBJECT ControlDeviceObject;
PVOID thread[THREADNUM];
KEVENT evKill[THREADNUM];
KEVENT evWork[IRPKINDNUM];
KTIMER kTimerCancel;
KDPC kTimerCancelDpc;
LONG lmsTime;
LARGE_INTEGER lrCurrentTime;
KSPIN_LOCK QueueLock;
LIST_ENTRY WorkItems[IRPKINDNUM];
operations
BOOLEAN IsFillColor;
ULONG FillColor;
SYSTEM_POWER_STATE SystemPowerState;
DEVICE_POWER_STATE DevicePowerState;
SYSTEM_POWER_STATE PreSystemPowerState;
DEVICE_POWER_STATE PreDevicePowerState;
PVOID pGpnpRemAddr;
IO_REMOVE_LOCK RemoveLock;
PGVIDEOFORMAT CurVideoFormat;
PGVIDEOFORMAT TempVideoFormat;
} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

xxxxx@gmail.com wrote:

Dear Tim
thank you very much.
Yes, there is a common member (IsCtrlDevice) in these two extension to see if it is a control object or device object. Please see the following code.

There’s a bug in here somewhere. Let’s review the evidence.

The crash is happening when you tried to complete an IRP_MJ_CREATE IRP.
The DTM tests don’t know anything about your control DO or how to open
it, so I don’t see how it could be create request for your control DO.
Instead, it must be a create request for your filter DO. But if that
were so, then the device extension should have IsCtrlDevice set to FALSE.

Are you sure you are setting “IsCtrlDevice” bit to FALSE in your filter DO?

Perhaps you need to check the device object in windbg to see which one
it is. In that dump, I believe the file name is at either 0012ecec or
0012ed48. You might see whether it’s the streaming device or your
private device.


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