Re: Does anyone know what this bugcheck is ? WdfDeviceInitSetReque

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

WdfDeviceInitSetRequestAttributes configures the attributes of a WDFREQUEST that the framework will create when it receives a PIRP. it does not configure the device's sync scope or execution level, you need to specify those on the WDFDEVICE itself when you create it via WdfDeviceCreate

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"hammerli22" <hammerli22@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:CB48DE82-BD21-4380-BBA4-3320239BD02E@xxxxxxxxxxxxxxxx
Thanks for your response,

Yes I am trying to do that and yes I did set the attributes when creating
the device obj via
WdfDeviceCreate. My problem is that when I set the attributes as in the
toaster program to:

attributes.SynchronizationScope = WdfSynchronizationScopeDevice;
attributes.ExecutionLevel = WdfExecutionLevelPassive;
WdfDeviceInitSetRequestAttributes(DeviceInit, &attributes);
// Create a framework driver object to represent our driver.
status = WdfDriverCreate( etc..


in the AddDevice routine, the call to WdfDeviceInitSetRequestAttributes
causes WDF to break into
the debugger. I have Parameters\Wdf,DbgBreakOnError,0x00010001,1 turned on
in the registry.

If I set the above attributes to the DRIVER OBJECT in the DriverEntry
routine when i create the DRIVER OBJECT, and then in AddDevice set the
atttributes to inherit from the parent , the
WdfDeviceInitSetRequestAttributes routine works without breaking into the
debugger and the rest of the
code runs fine. The sample code I included in previous post is the small
code i used to test this problem and
i took it from the toaster.c program. The problem happens on both LH RC1
and W2k3 SP2 though i don't think it matters, its running on a Itanium.

"Abhishek R" wrote:

Are you trying to get the framework to synchronize the IO callbacks for your
device? If so, you need to specify this in the attributes parameter that you
pass in while creating your device object (WdfDeviceCreate). Please see the
following link for more information -
http://msdn2.microsoft.com/en-us/library/aa490059.aspx

Note that the toaster sample also does this.


"hammerli22" <hammerli22@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F854C5E0-40DD-432B-A2AA-65EF73A2DC77@xxxxxxxxxxxxxxxx
> Thanks for the hint, can you help me understand this:
>
> I narrowed it down to these 2 piecs of code
>
> attributes.SynchronizationScope = WdfSynchronizationScopeDevice;
> attributes.ExecutionLevel = WdfExecutionLevelPassive;
>
> It seems that if you init these in AddDriver they cause the exception. > I
> had
> to
> init them in DriverEntry and the change them to inherit from parent in
> AddDriver
> and then everthing worked ok. Funny thing is that I used the sample > from
> the
> toaster.c file.
>
> Heres the entire driver code that i used to test it.
>
>
> NTSTATUS
> DriverEntry(
> __in PDRIVER_OBJECT DriverObject,
> __in PUNICODE_STRING RegistryPath
> )
> {
> NTSTATUS status = STATUS_SUCCESS;
> WDF_DRIVER_CONFIG config;
> WDF_OBJECT_ATTRIBUTES attributes;
>
> WDF_DRIVER_CONFIG_INIT( &config, XXXEvtDriverDeviceAdd );
> config.DriverPoolTag = MEMORY_POOL_TAG;
>
> WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
> attributes.SynchronizationScope = WdfSynchronizationScopeDevice;
> attributes.ExecutionLevel = WdfExecutionLevelPassive;
>
> // Create a framework driver object to represent our driver.
> status = WdfDriverCreate(
> DriverObject,
> RegistryPath,
> &attributes, // Driver Attributes
> &config, // Driver Config Info
> WDF_NO_HANDLE
> );
>
> return status;
> }
>
>
>
> NTSTATUS
> XXXEvtDriverDeviceAdd(
> __in WDFDRIVER Driver,
> __in PWDFDEVICE_INIT DeviceInit
> )
>
> {
> NTSTATUS status = STATUS_SUCCESS;
> WDF_OBJECT_ATTRIBUTES attributes;
>
> PAGED_CODE();
> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, DEVICE_CONTEXT);
>
> // attributes.SynchronizationScope = WdfSynchronizationScopeDevice;
> // attributes.ExecutionLevel = WdfExecutionLevelPassive;
>
> attributes.SynchronizationScope =
> WdfSynchronizationScopeInheritFromParent;
> attributes.ExecutionLevel = WdfExecutionLevelInheritFromParent;
>
> WdfDeviceInitSetRequestAttributes(DeviceInit, &attributes);
>
>
> return status;
> }
>
>
>
>
>
>
>
> "Doron Holan [MSFT]" wrote:
>
>> fix your symbols (.symfix in the debugger) and then send the stack. >> once
>> you do that, !wdflogdump <your driver name> will tell you why there >> was a
>> break. something was wrong with the WDF_OBJECT_ATTRIBUTES you passed >> in.
>>
>> d
>>
>> -- >> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "hammerli22" <hammerli22@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:04D3FC67-DD3D-4E6B-8BF9-A4AB054678F3@xxxxxxxxxxxxxxxx
>> >I have Wdf,DbgBreakOnError,0x00010001,1 turned on and when
>> > my driver loads the very first thing it does is break into the
>> > debugger,
>> > at first I thought that was normal in that when you hook up the
>> > debugger
>> > it automatically breaks into the debugger, but then i realized I did
>> > not
>> > call
>> > WdfVerifierDbgBreakPoint, instead its breaking into the debug >> > because
>> > of an exception, but the bugcheck code is 0. Any ideas ? If i hit >> > 'g'
>> > everthing runs normally.
>> >
>> > thanks in advance
>> >
>> > 1: kd> !analyze -v
>> > Connected to Windows 6001 Intel IA64 target, ptr64 TRUE
>> > Loading Kernel Symbols
>> > .........................................................................................................................
>> > Loading User Symbols
>> >
>> > Loading unloaded module list
>> > ......
>> > *** ERROR: Module load completed but symbols could not be loaded for
>> > Wdf01000.sys
>> > *******************************************************************************
>> > *
>> > *
>> > * Bugcheck Analysis
>> > *
>> > *
>> > *
>> > *******************************************************************************
>> >
>> > Unknown bugcheck code (0)
>> > Unknown bugcheck description
>> > Arguments:
>> > Arg1: 0000000000000000
>> > Arg2: 0000000000000000
>> > Arg3: 0000000000000000
>> > Arg4: 0000000000000000
>> >
>> > Debugging Details:
>> > ------------------
>> >
>> >
>> >
>> >
>> >
>> >
>> > PROCESS_NAME: System
>> >
>> > FAULTING_IP:
>> > nt!DbgBreakPoint+8 [d:\longhorn_rc0\base\ntos\rtl\mp\debugstb.s @ >> > 66]
>> > e0000000`88201988 break.i 0x80016
>> >
>> > EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
>> > ExceptionAddress: e000000088201988
>> > (nt!DbgBreakPoint+0x0000000000000008)
>> > ExceptionCode: 80000003 (Break instruction exception)
>> > ExceptionFlags: 00000000
>> > NumberParameters: 5
>> > Parameter[0]: 0000000000080016
>> > Parameter[1]: 0000000000000000
>> > Parameter[2]: 0000000000000000
>> > Parameter[3]: e000000088201980
>> > Parameter[4]: 0000040000000000
>> >
>> > ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A
>> > breakpoint
>> > has been reached.
>> >
>> > DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>> >
>> > BUGCHECK_STR: 0x0
>> >
>> > CURRENT_IRQL: 0
>> >
>> > LOCK_ADDRESS: e000000088556ca0 -- (!locks e000000088556ca0)
>> >
>> > Resource @ nt!PiEngineLock (0xe000000088556ca0) Exclusively owned
>> > Contention Count = 5
>> > Threads: e000012661eb3b60-01<*>
>> > 1 total locks, 1 locks currently held
>> >
>> > PNP_TRIAGE:
>> > Lock address : 0xe000000088556ca0
>> > Thread Count : 1
>> > Thread address: 0xe000012661eb3b60
>> > Thread wait : 0x61f6
>> >
>> > LAST_CONTROL_TRANSFER: from e0000106015e35e0 to e000000088201988
>> >
>> > STACK_TEXT:
>> > e0000106`07557680 e0000106`075585d8 e0000106`015e35e0 :
>> > e0000106`016eda90
>> > e0000126`6659a9d0 e0000106`016ed9e0 e0000106`075576e0 :
>> > nt!DbgBreakPoint+0x8
>> > [d:\longhorn_rc0\base\ntos\rtl\mp\debugstb.s @ 66]
>> > e0000106`07557680 e0000106`075585d8 e0000106`995dcef0 :
>> > e0000126`6659a9c0
>> > e0000106`07557888 e0000106`075576e0 00000000`c020020f :
>> > Wdf01000+0x3d5e0
>> > e0000106`07557680 e0000106`07558560 e0000106`995dd9f0 :
>> > e0000106`07557888
>> > e0000106`075576e0 e0000106`995dd9f0 00000000`0000028b :
>> > xxxxxx!WdfDeviceInitSetRequestAttributes+0x90
>> > [c:\winddk\6000\inc\wdf\kmdf\10\wdfdevice.h @ 2262]
>> > e0000106`07557690 e0000106`07558538 e0000106`0163a210 :
>> > 1ffffed9`99b3c728
>> > e0000106`07557888 e0000106`0163a210 00000000`00000c9d :
>> > xxxxxx!IpmiEvtDriverDeviceAdd+0x1f0 [c:\dev\xxxxdrv\src\xxxxdrv.c @
>> > 248]
>> > e0000106`07557870 e0000106`07558470 e0000106`016395e0 :
>> > ffffffff`ffffff7f
>> > e0000106`07557b30 e0000126`664c3968 ffffffff`c0000001 :
>> > Wdf01000+0x94210
>> > e0000106`07557bf0 e0000106`07558450 e0000000`883f5a30 :
>> > e0000126`6514ab10
>> > e0000126`622fe3a0 e0000000`883f5a30 00000000`0000040d :
>> > Wdf01000+0x935e0
>> > e0000106`07557bf0 e0000106`07558410 e0000000`889a44a0 :
>> > e0000126`622fe3a0
>> > e0000126`6514ab10 e0000106`016ce010 00000000`00000004 :
>> > nt!PpvUtilCallAddDevice+0x60
>> > [d:\longhorn_rc0\base\ntos\io\pnpmgr\verifier.c
>> > @ 75]
>> > e0000106`07557bf0 e0000106`075583c8 e0000000`889d0720 :
>> > 00000000`00000000
>> > e0000126`6514ab10 e0000106`016ce010 00000000`00000002 :
>> > nt!PnpCallAddDevice+0x120 >> > [d:\longhorn_rc0\base\ntos\io\pnpmgr\enum.c @
>> > 5507]
>> > e0000106`07557c00 e0000106`07558310 e0000000`889d2230 :
>> > e0000126`62308ef0
>> > 00000000`00000000 e0000126`622fe3a0 e0000126`622fe3a0 :
>> > nt!PipCallDriverAddDevice+0x9f0
>> > [d:\longhorn_rc0\base\ntos\io\pnpmgr\enum.c @
>> > 2182]
>> > e0000106`07557d40 e0000106`07558208 e0000000`889d2b10 :
>> > e0000106`07557f00
>> > e0000126`65144e10 e0000106`07557f10 00000000`00000000 :
>> > nt!PipProcessDevNodeTree+0x2c0
>> > [d:\longhorn_rc0\base\ntos\io\pnpmgr\enum.c
>> > @
>> > 4232]
>> > e0000106`07557f00 e0000106`075581d8 e0000000`883f89e0 :
>> > e0000126`65144e10
>> > e0000126`62308ef0 e0000106`07557f10 e0000000`883f89e0 :
>> > nt!PiRestartDevice+0x240 [d:\longhorn_rc0\base\ntos\io\pnpmgr\enum.c >> > @
>> > 3103]
>> > e0000106`07557f10 e0000106`07558140 e0000000`8816cb30 :
>> > 00000000`00000003
>> > 00000000`00000000 e0000126`65144e10 e0000106`07557f20 :
>> > nt!PnpDeviceActionWorker+0x3e0
>> > [d:\longhorn_rc0\base\ntos\io\pnpmgr\action.c
>> > @ 559]
>> > e0000106`07557f20 e0000106`07558070 e0000000`88656d40 :
>> > e0000000`8813e0a0
>> > 00000000`00000000 e0000126`61eb3b60 00000000`00000000 :
>> > nt!ExpWorkerThread+0x270 [d:\longhorn_rc0\base\ntos\ex\worker.c @ >> > 1191]
>> > e0000106`07557f30 e0000106`07558010 e0000000`88201250 :
>> > e0000000`8813e1f8
>> > 00000000`00000001 e0000106`07557f40 e0000126`61eb3b60 :
>> > nt!PspSystemThreadStartup+0x100 >> > [d:\longhorn_rc0\base\ntos\ps\psexec.c
>> > @
>> > 5185]
>> > e0000106`07557f50 e0000106`07558000 00000000`00000000 :
>> > 00000000`00000000
>> > 00000000`00000000 e0000000`8813e1f8 00000000`00000001 :
>> > nt!KiThreadStartup+0x70 [d:\longhorn_rc0\base\ntos\ke\mp\threadbg.s >> > @
>> > 245]
>> >
>> >
>> > STACK_COMMAND: kb
>> >
>> > FOLLOWUP_IP:
>> > xxxxxx!WdfDeviceInitSetRequestAttributes+90
>> > [c:\winddk\6000\inc\wdf\kmdf\10\wdfdevice.h @ 2262]
>> > e0000106`995dcef0 adds gp = 0,r36 ;;
>> >
>> > FAULTING_SOURCE_CODE:
>> > 2258: __in
>> > 2259: PWDF_OBJECT_ATTRIBUTES RequestAttributes
>> > 2260: )
>> > 2261: {
>> >> 2262: ((PFN_WDFDEVICEINITSETREQUESTATTRIBUTES)
>> >> WdfFunctions[WdfDeviceInitSetRequestAttributesTableIndex])(WdfDriverGlobals,
>> >> DeviceInit, RequestAttributes);
>> > 2263: }
>> > 2264:
>> > 2265: //

.

Relevant Pages

  • Re: Does anyone know what this bugcheck is ? WdfDeviceInitSetReque
    ... I am calling WdfDeviceInitSetRequestAttributes then ... it breaks into the debugger when it calls WdfDeviceInitSetRequestAttributes; ... attributes.ExecutionLevel = WdfExecutionLevelInheritFromParent; ... // Create a framework driver object to represent our driver. ...
    (microsoft.public.development.device.drivers)
  • Enabling busenum.dll makes application exit difficult
    ... by disabling touch driver and spi driver. ... PB Debugger Kernel debugger connected. ... FILESYS: Waiting for kernel to be ready to launch apps ... !AFD: ...
    (microsoft.public.windowsce.platbuilder)
  • Re: CTooltipCtrl with custom paint causing SYSTEM CRASH!!!!!
    ... you probably have a bad driver. ... you might have found a bug in the kernel. ... this might be a hardware error or a device driver error. ... If the kernel debugger is connected and running when watchdog detects ...
    (microsoft.public.vc.mfc)
  • Re: CTooltipCtrl with custom paint causing SYSTEM CRASH!!!!!
    ... you probably have a bad driver. ... you might have found a bug in the kernel. ... If you copy the output from!analyze -v and post it here, I'll take a stab at analyzing ... If the kernel debugger is connected and running when watchdog detects ...
    (microsoft.public.vc.mfc)
  • Re: Blue screen crashes
    ... Some common problems are exception code 0x80000003. ... If this happens, make sure a debugger gets connected, and the ... What Warning and Error Reports appear in Event Viewer since it's ... If all goes okay without errors then the Printer driver was ...
    (microsoft.public.windowsxp.help_and_support)