Thanks d.
But where can I get the symbols from?
I am seeing a crash when driver for my child device sends an query interface request down to parent driver.
The stack trace when the callback receives the request looks as follows:
kd> g
Breakpoint 11 hit
nvnetbus!CDEvtDeviceProcessQueryInterfaceRequest:
97494c30 8bff mov edi,edi
kd> kb
ChildEBP RetAddr Args to Child
842411e0 80731b2f 7246a4a8 8bc7a160 84241408 nvnetbus!CDEvtDeviceProcessQueryInterfaceRequest [c:\drivers\windows\kmdf\nvnwcdevt.c @ 1157]
WARNING: Frame IP not in any known module. Following frames may be wrong.
8424127c 81adb652 83ad9680 8c69ef48 00000000 0x80731b2f
842412a0 81897f05 8c69efdc 8c69ef48 83ad9680 nt!RtlCompressBuffer+0x3bfe
842412fc 81adb652 8db693f0 8c69ef48 00000000 nt!IofCallDriver+0x1b
84241320 81897f05 8c69efdc 84241368 8db693f0 nt!RtlCompressBuffer+0x3bfe
842413c4 98d0c39b 8938ce20 74562fe8 98d19568 nt!IofCallDriver+0x1b
842413e8 98d0c30d 74562fe8 98d19568 84241408 NVENETFD+0x439b
84241444 98d08947 8dac34c4 8dac368c 8dac36a0 NVENETFD+0x430d
842416f4 818a50f1 c0420f00 00000000 89357ec0 NVENETFD+0x947
842419c0 81adb652 8db693f0 87c2ef48 87c2f000 nt!NtFreeVirtualMemory+0x39c4
842419e4 81897f05 87c2efdc 84241a5c 8db693f0 nt!RtlCompressBuffer+0x3bfe
842419f8 819b2e8d 00000000 83ad9680 8bb59b20 nt!IofCallDriver+0x1b
84241a14 818d1222 84241a38 818d1089 8bb59b20 nt!IoReportResourceUsage+0x10b06
84241a60 819bc64d 818d1089 8bb59b20 83ad94f8 nt!IoTranslateBusAddress+0x1b23
84241abc 819bbf4c 8bb59b20 00000044 00000000 nt!IoReportResourceUsage+0x1a2c6
84241ad8 819b967e 00000000 00000000 834163a8 nt!IoReportResourceUsage+0x19bc5
84241cd4 819b8be5 834163a8 8ba2a7c8 84241d00 nt!IoReportResourceUsage+0x172f7
84241d08 818d09b1 83066ad0 818fddbc 8192c4c0 nt!IoReportResourceUsage+0x1685e
84241d44 81865b50 00000000 83040d90 83066ad0 nt!IoTranslateBusAddress+0x12b2
84241d7c 81a2ee1c 00000000 8424a680 00000000 nt!ExQueueWorkItem+0x2d8
I return from this callback successfully. I move to caller of this function by using “shift+F11” in windbg.
When I do it again to go up one more level in call stack trace, I see a crash. The stack trace just b4 the crash and
just after the crash look like:
kd> kb
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
8424121c 8072dbd8 84241250 8424123f 80750748 0x80731b60
8424127c 81adb652 83ad9680 8c69ef48 00000000 0x8072dbd8
842412a0 81897f05 8c69efdc 8c69ef48 83ad9680 nt!RtlCompressBuffer+0x3bfe
842412fc 81adb652 8db693f0 8c69ef48 00000000 nt!IofCallDriver+0x1b
84241320 81897f05 8c69efdc 84241368 8db693f0 nt!RtlCompressBuffer+0x3bfe
842413c4 98d0c39b 8938ce20 74562fe8 98d19568 nt!IofCallDriver+0x1b
842413e8 98d0c30d 74562fe8 98d19568 84241408 NVENETFD+0x439b
84241444 98d08947 8dac34c4 8dac368c 8dac36a0 NVENETFD+0x430d
842416f4 818a50f1 c0420f00 00000000 89357ec0 NVENETFD+0x947
842419c0 81adb652 8db693f0 87c2ef48 87c2f000 nt!NtFreeVirtualMemory+0x39c4
842419e4 81897f05 87c2efdc 84241a5c 8db693f0 nt!RtlCompressBuffer+0x3bfe
842419f8 819b2e8d 00000000 83ad9680 8bb59b20 nt!IofCallDriver+0x1b
84241a14 818d1222 84241a38 818d1089 8bb59b20 nt!IoReportResourceUsage+0x10b06
84241a60 819bc64d 818d1089 8bb59b20 83ad94f8 nt!IoTranslateBusAddress+0x1b23
84241abc 819bbf4c 8bb59b20 00000044 00000000 nt!IoReportResourceUsage+0x1a2c6
84241ad8 819b967e 00000000 00000000 834163a8 nt!IoReportResourceUsage+0x19bc5
84241cd4 819b8be5 834163a8 8ba2a7c8 84241d00 nt!IoReportResourceUsage+0x172f7
84241d08 818d09b1 83066ad0 818fddbc 8192c4c0 nt!IoReportResourceUsage+0x1685e
84241d44 81865b50 00000000 83040d90 83066ad0 nt!IoTranslateBusAddress+0x12b2
84241d7c 81a2ee1c 00000000 8424a680 00000000 nt!ExQueueWorkItem+0x2d8
kd> bp /1 /c @$csp @$ra;g
kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* 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: 8424a77f, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 8db95d34, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
FAULTING_MODULE: 81800000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 44b1f1bc
WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
8424a77f
FAULTING_IP:
+ffffffff8db95d34
8db95d34 18bd63950000 sbb [ebp+0x9563],bh
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_BETA2
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from 818d3be0 to 8186e51c
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
84240d3c 818d3be0 00000003 00000000 83066ad0 nt!DbgBreakPointWithStatus+0x4
842410e8 8189ae09 00000050 8424a77f 00000001 nt!KeBugCheckEx+0xc01
84241164 8187c450 00000001 8424a77f 00000000 nt!KeInsertQueueApc+0x177
842411ec 80731b65 00020001 83adf4a8 84241250 nt!Kei386EoiHelper+0x2718
8424121c 8072dbd8 84241250 8424123f 80750748 Wdf01000+0x4ab65
84241230 80731044 83adf4a8 00241250 00000000 Wdf01000+0x46bd8
84241254 8071ad5b 8c69ef48 8424127c 8071af63 Wdf01000+0x4a044
84241260 8071af63 83ad9680 8c69ef48 89350948 Wdf01000+0x33d5b
8424127c 81adb652 83ad9680 8c69ef48 00000000 Wdf01000+0x33f63
842412a0 81897f05 8c69efdc 8c69ef48 83ad9680 nt!RtlCompressBuffer+0x3bfe
842412b4 841d10d8 893a7d18 8c69ef48 8db693f0 nt!IofCallDriver+0x1b
842412fc 81adb652 8db693f0 8c69ef48 00000000 ndis!NdisRegisterProtocol+0xdac
84241320 81897f05 8c69efdc 84241368 8db693f0 nt!RtlCompressBuffer+0x3bfe
84241334 8074978d 8db693f0 80040001 00000000 nt!IofCallDriver+0x1b
84241350 8074905e 8db693f0 8db693f0 84241388 Wdf01000+0x6278d
84241360 8071b82c 8c69ef48 98d19568 84241408 Wdf01000+0x6205e
84241388 8070ae35 98d19568 84241408 74560038 Wdf01000+0x3482c
842413c4 98d0c39b 8938ce20 74562fe8 98d19568 Wdf01000+0x23e35
842413e8 98d0c30d 74562fe8 98d19568 84241408 NVENETFD+0x439b
84241444 98d08947 8dac34c4 8dac368c 8dac36a0 NVENETFD+0x430d
84241670 841d3b48 8db694a8 00000000 842416a4 NVENETFD+0x947
84241910 841d33b2 94a84b08 8db694a8 89357ec0 ndis!NdisMRegisterInterruptEx+0x1583
84241948 841d322d 94a84b08 8db693f0 8dbf6cc8 ndis!NdisMRegisterInterruptEx+0xded
84241970 841d0c4a 8db693f0 84fca7c0 94a7f148 ndis!NdisMRegisterInterruptEx+0xc68
842419c0 81adb652 8db693f0 87c2ef48 87c2f000 ndis!NdisRegisterProtocol+0x91e
842419e4 81897f05 87c2efdc 84241a5c 8db693f0 nt!RtlCompressBuffer+0x3bfe
842419f8 819b2e8d 00000000 83ad9680 8bb59b20 nt!IofCallDriver+0x1b
84241a14 818d1222 84241a38 818d1089 8bb59b20 nt!IoReportResourceUsage+0x10b06
84241a60 819bc64d 818d1089 8bb59b20 83ad94f8 nt!IoTranslateBusAddress+0x1b23
84241abc 819bbf4c 8bb59b20 00000044 00000000 nt!IoReportResourceUsage+0x1a2c6
84241ad8 819b967e 00000000 00000000 834163a8 nt!IoReportResourceUsage+0x19bc5
84241cd4 819b8be5 834163a8 8ba2a7c8 84241d00 nt!IoReportResourceUsage+0x172f7
84241d08 818d09b1 83066ad0 818fddbc 8192c4c0 nt!IoReportResourceUsage+0x1685e
84241d44 81865b50 00000000 83040d90 83066ad0 nt!IoTranslateBusAddress+0x12b2
84241d7c 81a2ee1c 00000000 8424a680 00000000 nt!ExQueueWorkItem+0x2d8
84241dc0 8187dece 81865a53 00000001 00000000 nt!PsResumeProcess+0x8f81
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x72e
STACK_COMMAND: kb
FOLLOWUP_IP:
Wdf01000+4ab65
80731b65 8b4334 mov eax,[ebx+0x34]
FAULTING_SOURCE_CODE:
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: Wdf01000+4ab65
MODULE_NAME: Wdf01000
IMAGE_NAME: Wdf01000.sys
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
I understand that there is some issue with memory access violation.
But I dont understand what is WDF doing that results in this violation.
I seem to be returning proper interface structure in response to the query.
Apart from Context pointer, there is no other pointer involed here.
kd> dt pNVBusInterfaceStandard
Local var @ 0x842411c0 Type _NVBUS_INTERFACE_STANDARD*
0x84241408
+0x000 Size : 0x38
+0x004 Version : 0x20001
+0x008 Context : 0x8db95d18
+0x00c InterfaceReference : 0x97494680 WdfDeviceInterfaceDereferenceNoOp+0
+0x010 InterfaceDereference : 0x97494680 WdfDeviceInterfaceDereferenceNoOp+0
+0x014 DeviceLocationHandle : 0xa0000
+0x018 MultiVlanEnabled : 0
+0x01c VirtualInterfaceNumber : 0
+0x020 VirtualDummyIPBE : [4] 0
+0x030 PhysicalDeviceObject : (null)
+0x034 pfnAttachInterface : 0x99aadb30 NRM_AttachInterface+0
At a loss to understand whats happening thats resulting in this crash…
Thanks in advance,
-Praveen
“Doron Holan” wrote in message news:xxxxx@ntdev…
The typical pattern that you see in KMDF is that all the paraetmers to a
XXX_INIT() function are required to use the structure/API properly.
This is why the INIT() function exists, to properly construct the
structure w/out having to dig too deep into the docs/samples to figure
it out.
Read my on entry on how to view the log at
http://blogs.msdn.com/doronh/archive/2006/07/31/684531.aspx
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, July 31, 2006 1:20 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] What are the reasons when an inf file does not match
device-id indicated during installation?
Hi d,
Looks like the problem was that I specified NULL for 2nd argument below.
I was providing EvtDeviceProcessQueryInterfaceRequest callback and was
under the impression that NULL is allowed incase a callback is required.
Looks like that is not the case from the error I got and also I dont
see optional word mentioned besides the argument in DDK for this
interface.
Thought I read somewhere in the doc that 2nd argument was optional
if a callback to process query interface request was provided. Looks
like
I have mistaken.
VOID FORCEINLINE
WDF_QUERY_INTERFACE_CONFIG_INIT(
OUT PWDF_QUERY_INTERFACE_CONFIG InterfaceConfig,
IN PINTERFACE Interface,
IN CONST GUID* InterfaceType,
IN OPTIONAL PFN_WDF_DEVICE_PROCESS_QUERY_INTERFACE_REQUEST
EvtDeviceProcessQueryInterfaceRequest
);
I found wdfkd.dll under a diff location no my PC.
!load c:\winddk\5384\wdf\kmdf10\bin\x86\wdfkd.dll succeeded.
But search for wdfkd.wdfsearchpath failed under c:\winddk\5384.
Neither do i find the dump command: wdfkd.wdflogdump in my ddk.
Can you point to me place where I can pull these from?
Are these available in DDK from later builds?
“your driver name, no” Does no.sys did you mean the instance no?
Thanks in advance,
-Praveen
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Since EvtChildListCreateDevice is being called, KMDF has successfully
invalidated the device relations and is trying to create a PDO for your
device. Are you sure you are returning NT_SUCCESS from
EvtChildListCreateDevice? When creating the PDO, which pnp/power/pdo
callbacks are you assigning to the PDO? Are you returning NT_SUCCESS
from each of those?
The KMDF log should tell you what is going on. You can view the log by
loading wdfkd.dll from the DDK installation point with a fully qualified
path (if you don’t, you will get the debugger’s version which could be
older).
!load c:\winddk\wdf\kmdf10\bin\x86\wdfkd.dll
!c:\winddk\wdf\kmdf10\bin\x86\wdfkd.wdfsearchpath
c:\winddk\wdf\kmdf10\symbols\x86fre (or whatever arch+build type you are
on)
!c:\winddk\wdf\kmdf10\bin\x86\wdfkd.wdflogdump .sys>
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, July 31, 2006 12:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] What are the reasons when an inf file does not match
device-id indicated during installation?
Hi,
The problem is bigger… I dont see the child-device in the device
manager.
The parent device driver gets installed and returns successfully.
Child device creation through WdfDeviceCreate() happens successfully
w/o any error.
Dont get why driverentry for child device does not get called?
Moreover I had registered compare routine for ChildDevice
IdentificationDescription compare. I expected it to be called, but its
not getting called either.
Any idea what could be going wrong?
Looking at setupapi.dev.log under %windir%\inf directory shows that
parent device gets installed.
It does not show any trace of search for the child device-driver (inf)
file in this log.
Is it possible to figure out what is happening when I create child
device framework object. Why does it return success,but do not see any
action?
Thanks in advance,
-Praveen
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Lookat the setup logs in %windir%. You should also consider turning on
verbose logging if there is not enough info for your device. If you are
on XP SP2 and later, you can goto device manager, open up the properties
for the child device, open the Details tab. On the details tab, look at
the compatible/instance/hw IDs, are they properly listed?
Also, for a PDO, KMDF autotmatically sets the auto generated named flag
(again, it’s a universal WDM rule so KMDF implements it on behalf of the
driver writer). Furthermore, all KMDF devices are created with the
FILE_DEVICE_SECURE_OPEN flag.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Monday, July 31, 2006 7:39 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] What are the reasons when an inf file does not match
device-id indicated during installation?
I am enumerating my child devices within EvtPrepareHardware() routine.
I am registering the callback routine : EvtChildListCreateDevice(),
that creates the child device.
I receive the correct Identification Description structure that was
passed from my Bus Driver(using
WdfChildListAddOrUpdateChildDescriptionAsPresent().).
EvtChildListCreateDevice() gets called. Within my
EvtChildListCreateDevice() callback routine,
I use the following code to initialize the device-id/hardware-id for
the child device (the information I got from parent in the form of
Description).
//
// Set DeviceType
//
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_NETWORK);
//
// Set Device Characteristics
//
WdfDeviceInitSetCharacteristics(DeviceInit,
FILE_AUTOGENERATED_DEVICE_NAME
|FILE_DEVICE_SECURE_OPEN,TRUE);
WdfDeviceInitSetExclusive(DeviceInit, FALSE);
//
// Provide DeviceID, HardwareIDs, CompatibleIDs and InstanceId
//
RtlInitUnicodeString(&deviceId, HardwareIds);
status = WdfPdoInitAssignDeviceID(DeviceInit, &deviceId);
if (!NT_SUCCESS(status)) {
return status;
}
//
// NOTE: same string is used to initialize hardware id too
//
status = WdfPdoInitAddHardwareID(DeviceInit, &deviceId);
if (!NT_SUCCESS(status)) {
return status;
}
status = WdfPdoInitAddCompatibleID(DeviceInit, &compatId );
if (!NT_SUCCESS(status)) {
return status;
}
At the end of EvtChildListCreateDevice() I create the device
successfully and exit from this routine.
I see my Bus driver getting installed, but not the driver for my
child-devices.
Stepping through the debugger shows that hardwareids/Deviceids I
specify are all correct and match the one with the inf file.
Any ideas on what could be going wrong here. Why is the OS not able to
find an inf file that matches my child-deviceid?
Thanks,
-Praveen
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer