HCK: deviceless driver crashes in IovUtilMarkDeviceObject

I have a driver which provides just a IOCTL interface, but does not support a device.
(This is a special “demo driver” for customers who want to test our API but do not have
bought a device license. The production drivers from the same code base pass HCK.)

DriverEvtDeviceAdd() is just a dummy, which does NOT call a WdfCreateDevice().
This works well for years, but crashes as I begin HCK testing now.

When testing under HCK, the BSOD happens after passing DriverEvtDeviceAdd()

Stack:
868b29c0 82c5f080 868b2a98 82e0a9f5 84fe5980 nt!IovUtilMarkDeviceObject+0x9
868b29c8 82e0a9f5 84fe5980 00000000 84fe57c8 nt!IovUtilMarkStack+0x52
868b2a98 82e09edc 84fe57c8 868b2cc8 00000000 nt!PipCallDriverAddDevice+0x60a
868b2c94 82dd5e5e 84fd6a60 8c511ad8 868b2cc8 nt!PipProcessDevNodeTree+0x15d
868b2cd4 82c61d09 8c511ad8 82db1be0 84fc8a70 nt!PiProcessStartSystemDevices+0x6d
868b2d00 82cca14b 00000000 00000000 84fc8a70 nt!PnpDeviceActionWorker+0x241
868b2d50 82e56141 00000001 d63a5534 00000000 nt!ExpWorkerThread+0x10d
868b2d90 82cfd559 82cca03e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Any pointers for further reading?

Thanks,

Joerg Hoppe, PEAK-System Technik, Germany

------------------------------- Full log ----------------------
Connected to Windows 7 7601 x86 compatible target at (Mon Sep 15 08:19:26.313 2014 (UTC + 2:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: srv*;T:\PEAK\driver\Peakcan4\PCAN_VIRTUAL\OBJCHK_WXP_x86\i386\symbols
Executable search path is:
Windows 7 Kernel Version 7601 MP (1 procs) Free x86 compatible
Built by: 7601.18409.x86fre.win7sp1_gdr.140303-2144
Machine Name:
Kernel base = 0x82c4d000 PsLoadedModuleList = 0x82d965b0
System Uptime: not available
*******************************************************************************
*
* This is the string you add to your checkin description
* Driver Verifier: Enabled for Wdf01000.sys on Build 7601 dauz9m6m0utaLKw9FJCpAH
*
*******************************************************************************
*******************************************************************************
*
* This is the string you add to your checkin description
* Driver Verifier: Enabled for MSDMFilt.sys on Build 7601 2F4VQKOFC9HIE0dXjwzFqH
*
*******************************************************************************
*******************************************************************************
*
* This is the string you add to your checkin description
* Driver Verifier: Enabled for IoSpy.sys on Build 7601 odRJBgVAjBZc6AWYipsjiH
*
*******************************************************************************
*******************************************************************************
*
* This is the string you add to your checkin description
* Driver Verifier: Enabled for PCAN_VIRTUAL.SYS on Build 7601 OsDdy82nPFIKF5fcwnVQ1G
*
*******************************************************************************
PCAN_VIRT [0 | 0:0] Tracing filter #0: Tracelevel = 4, TraceEventMask = 0x0
PCAN_VIRT [1 | 0:0] Tracing filter #0: Tracelevel = 4, TraceEventMask = 0x6
PCAN_VIRT [2 | 0:0] Tracing filter #1: Tracelevel = 0, TraceEventMask = 0x0
PCAN_VIRT [3 | 0:0] Tracing filter #1: Tracelevel = 0, TraceEventMask = 0x0
PCAN_VIRT [0 | 0:0 | 17.397.795 us | driver:0110] In DriverEntry of PCAN_VIRTUAL 4.0.9.15586d
PCAN_VIRT [1 | 0:0 | 17.409.755 us | driver:0167] RegistryPath = \REGISTRY\MACHINE\SYSTEM\ControlSet003\services\PCAN_VIRTUAL
PCAN_VIRT [2 | 0:0 | 17.421.562 us | driver:0492] Peakcan Kernel Mode Driver Framework (verifier on) version 01.011.0, built at Sep 8 2014 13:02:02
PCAN_VIRT [3 | 0:0 | 17.432.063 us | driver:0502] Yes, framework version is 1.7
PCAN_VIRT [4 | 0:0 | 17.442.962 us | driver:0594] Systemdate: 15.9.2014, sysdate=151468
PCAN_VIRT [5 | 0:2 | 17.454.737 us | canapi:0413] CAN_Init() of PCAN_VIRTUAL WDF V 4.0.9.15586d (compiled at Sep 8 2014 13:02:06) passed.
PCAN_VIRT [6 | 0:2 | 17.466.538 us | canapi:0414] Good luck!!!
PCAN_VIRT [7 | 0:0 | 17.477.126 us | canapi_params:3897] RegReadParams(): final key = “\REGISTRY\MACHINE\SYSTEM\ControlSet003\services\PCAN_VIRTUAL\DriverParams”
PCAN_VIRT [8 | 0:0 | 17.487.584 us | canapi_params:3956] RegReadParams(): Setting CAN_PARAM_ISRTIMEOUT to 0
PCAN_VIRT [9 | 0:0 | 17.498.429 us | driver:0205] Timer resolution increased to 976 us.
KDTARGET: Refreshing KD connection
PCAN_VIRT [10 | 2:0 | 20.659.006 us | driver:0299] Enter DriverEvtDeviceAdd() of PCAN_VIRTUAL 4.0.9.15586d
PCAN_VIRT [11 | 2:0 | 20.670.793 us | driver:0307] WdfFdoInitQueryProperty(DevicePropertyDeviceDescription) = “PCAN-VIRTUAL”
PCAN_VIRT [12 | 2:0 | 20.681.285 us | driver:0309] WdfFdoInitQueryProperty(DevicePropertyHardwareID) = “root\pcan_virtual”
PCAN_VIRT [13 | 2:0 | 20.691.825 us | driver:0315] WdfFdoInitQueryProperty(DevicePropertyBootConfigurationTranslated) = “root\pcan_virtual”
PCAN_VIRT [14 | 2:0 | 20.702.290 us | driver:0317] WdfFdoInitQueryProperty(DevicePropertyClassName) = “CAN-Hardware”
PCAN_VIRT [15 | 2:0 | 20.712.794 us | driver:0319] WdfFdoInitQueryProperty(DevicePropertyClassGuid) = “{c38c9d86-471e-4d6b-9fb6-78dda20e3f70}”
PCAN_VIRT [16 | 2:0 | 20.723.322 us | driver:0321] WdfFdoInitQueryProperty(DevicePropertyDriverKeyName) = “{c38c9d86-471e-4d6b-9fb6-78dda20e3f70}\0022”
PCAN_VIRT [17 | 2:0 | 20.733.796 us | driver:0323] WdfFdoInitQueryProperty(DevicePropertyManufacturer) = “PEAK-System Technik GmbH”
PCAN_VIRT [18 | 2:0 | 20.744.318 us | driver:0329] WdfFdoInitQueryProperty(DevicePropertyPhysicalDeviceObjectName) = “\Device\00000050”
PCAN_VIRT [19 | 2:0 | 20.754.762 us | driver:0337] WdfFdoInitQueryProperty(DevicePropertyEnumeratorName) = “Root”
PCAN_VIRT [20 | 2:0 | 20.765.389 us | driver:0343] WdfFdoInitQueryProperty(DevicePropertyInstallState) = “”
PCAN_VIRT [21 | 2:0 | 20.775.769 us | driver:0345] WdfFdoInitQueryProperty(DevicePropertyRemovalPolicy) = “”
PCAN_VIRT [22 | 2:0 | 20.786.323 us | driver:0373] DevicePropertyHardwareID[0]= “root\pcan_virtual”
PCAN_VIRT [23 | 2:0 | 20.796.800 us | driver:0422] Device of group “_SOURCE_DRIVER_WITHOUT_KMDF_DEVICES” detected
PCAN_VIRT [24 | 2:0 | 20.807.253 us | driver:0443] WDF device for CANAPI of driver PCAN_VIRTUAL created

*** Fatal System Error: 0x0000007e
(0xC0000005,0x82C5F092,0x868B28FC,0x868B24E0)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 7 7601 x86 compatible target at (Mon Sep 15 08:19:46.383 2014 (UTC + 2:00)), ptr64 FALSE
Loading Kernel Symbols


Loading User Symbols

Loading unloaded module list

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

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, 82c5f092, 868b28fc, 868b24e0}

Probably caused by : ntkrpamp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
82cc77b8 cc int 3
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 82c5f092, The address that the exception occurred at
Arg3: 868b28fc, Exception Record Address
Arg4: 868b24e0, Context Record Address

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘ks’ and ‘1394ohci.sys’ overlap

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt!IovUtilMarkDeviceObject+9
82c5f092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

EXCEPTION_RECORD: 868b28fc – (.exr 0xffffffff868b28fc)
ExceptionAddress: 82c5f092 (nt!IovUtilMarkDeviceObject+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000000b0
Attempt to read from address 000000b0

CONTEXT: 868b24e0 – (.cxr 0xffffffff868b24e0)
eax=00000000 ebx=84fe57c8 ecx=00000002 edx=9008bee0 esi=84fe57c8 edi=00000000
eip=82c5f092 esp=868b29c4 ebp=868b29c8 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210202
nt!IovUtilMarkDeviceObject+0x9:
82c5f092 8b80b0000000 mov eax,dword ptr [eax+0B0h] ds:0023:000000b0=???
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 000000b0

READ_ADDRESS: 000000b0

FOLLOWUP_IP:
nt!IovUtilMarkDeviceObject+9
82c5f092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: 82db3cc0 – (!locks 82db3cc0)

Resource @ nt!PiEngineLock (0x82db3cc0) Exclusively owned
Contention Count = 2
NumberOfExclusiveWaiters = 1
Threads: 84fc8a70-01<*>
Threads Waiting On Exclusive Access:
84fc8798

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x82db3cc0
Thread Count : 1
Thread address: 0x84fc8a70
Thread wait : 0x4a6

LAST_CONTROL_TRANSFER: from 82d2bd5f to 82cc77b8

STACK_TEXT:
868b29c0 82c5f080 868b2a98 82e0a9f5 84fe5980 nt!IovUtilMarkDeviceObject+0x9
868b29c8 82e0a9f5 84fe5980 00000000 84fe57c8 nt!IovUtilMarkStack+0x52
868b2a98 82e09edc 84fe57c8 868b2cc8 00000000 nt!PipCallDriverAddDevice+0x60a
868b2c94 82dd5e5e 84fd6a60 8c511ad8 868b2cc8 nt!PipProcessDevNodeTree+0x15d
868b2cd4 82c61d09 8c511ad8 82db1be0 84fc8a70 nt!PiProcessStartSystemDevices+0x6d
868b2d00 82cca14b 00000000 00000000 84fc8a70 nt!PnpDeviceActionWorker+0x241
868b2d50 82e56141 00000001 d63a5534 00000000 nt!ExpWorkerThread+0x10d
868b2d90 82cfd559 82cca03e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!IovUtilMarkDeviceObject+9

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 53158c8f

STACK_COMMAND: .cxr 0xffffffff868b24e0 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

Followup: MachineOwner

xxxxx@t-online.de wrote:

I have a driver which provides just a IOCTL interface, but does not support a device.
(This is a special “demo driver” for customers who want to test our API but do not have
bought a device license. The production drivers from the same code base pass HCK.)

DriverEvtDeviceAdd() is just a dummy, which does NOT call a WdfCreateDevice().
This works well for years, but crashes as I begin HCK testing now.

How do you expect clients to access your device object if you don’t
create one? ALL KMDF drivers need to call WdfDeviceCreate. ALL of
them. Clients cannot send you ioctls if you do not have a device object.

The fact that there is no hardware is irrelevant. The only difference
between this driver and your real driver is the identity of the bus
driver that created you. Everything else should be exactly identical.


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