crash in lower bus driver w/o reference to device driver

OSR_Community_User · March 4, 2010, 8:01am

Hi All,
I've received a customer crash report happing in conjunction with our
1394 device (WDM driver - without WDF). The mini dump itself does not
contain any reference to our driver though.
Is there anything I could test or check to know or exclude the
involvements of our driver?
Thanks for any idea or hint,

Thanks,
Hagen.

Loading Dump File [O:\030310-12433-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
srv*c:\symbols*http://msdl.microsoft.com/download/symbols;o:\objfre_wnet_amd64\amd64
Executable search path is: o:\objfre_wnet_amd64\amd64
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff80002a1d000 PsLoadedModuleList = 0xfffff80002c5ae50
Debug session time: Wed Mar 3 21:01:35.340 2010 (UTC + 1:00)
System Uptime: 0 days 1:11:56.604
Loading Kernel Symbols
...............................................................
................................................................
....................
Loading User Symbols
Loading unloaded module list
.................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 12E, {fffffa8009cfee40, fffffa800a3c5a40, fffffa800a37d000, 800}

Probably caused by : 1394BUS.SYS ( 1394BUS!Bus1394AsyncCompletionRoutine+b6 )

Followup: MachineOwner

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

INVALID_MDL_RANGE (12e)
A driver has called the IoBuildPartialMdl() function and passed it an MDL
to map part of a source MDL, but the virtual address range specified is
outside the range in the source MDL. This is a driver bug. The source
and target MDLs, as well as the address range length to be mapped are the
arguments to the IoBuildPartialMdl() function, i.e.;
IoBuildPartialMdl(
IN PMDL SourceMdl,
IN OUT PMDL TargetMdl,
IN PVOID VirtualAddress,
IN ULONG Length
)
Arguments:
Arg1: fffffa8009cfee40
Arg2: fffffa800a3c5a40
Arg3: fffffa800a37d000
Arg4: 0000000000000800

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x12E

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002ae41d6 to fffff80002a8ef00

STACK_TEXT:
fffff88002f1baa8 fffff80002ae41d6 : 000000000000012e fffffa8009cfee40 fffffa800a3c5a40 fffffa800a37d000 :
nt!KeBugCheckEx
fffff88002f1bab0 fffff88005ccf6da : fffffa8009fd4958 fffffa800a3c5a40 fffffa800b0cce50 0000000000000000 : nt! ??
::FNODOBFM::string'+0x2afc fffff88002f1baf0 fffff80002a91516 : fffffa800b0ccf23
0000000000000000 fffffa800bd0eda0 fffff88005cd1b4d : 1394BUS!Bus1394AsyncCompletionRoutine+0xb6 fffff88002f1bb30 fffff88005cc32b4 : fffffa8009abab08
fffffa8009ab9100 fffffa8009ab91a0 0000000000000000 : nt!IopfCompleteRequest+0x3a6 fffff88002f1bc10 fffff88005cc282e : 0000000000000001
fffff88000000000 fffff880065483c0 fffff880009e7180 : ohci1394!OhciHandleAsyncResponse+0x584 fffff88002f1bc70 fffff80002a9a5dc : fffff880009e7180
fffffa8009ab91a0 fffffa8009abaa50 0000000000000000 : ohci1394!OhciDpc+0x3f6 fffff88002f1bcd0 fffff80002a976fa : fffff880009e7180
fffff880009f20c0 0000000000000000 fffff88005cc2438 : nt!KiRetireDpcList+0x1bc fffff88002f1bd80 0000000000000000 : 0000000000000000
0000000000000000 0000000000000000 00000000`00000000 :
nt!KiIdleLoop+0x5a

STACK_COMMAND: kb

FOLLOWUP_IP:
1394BUS!Bus1394AsyncCompletionRoutine+b6
fffff880`05ccf6da 8b8794000000 mov eax,dword ptr [rdi+94h]

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: 1394BUS!Bus1394AsyncCompletionRoutine+b6

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: 1394BUS

IMAGE_NAME: 1394BUS.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bcc0e

FAILURE_BUCKET_ID: X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6

BUCKET_ID: X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6

Followup: MachineOwner

Mark_Roddy · March 4, 2010, 1:30pm

It is in the 1394 stack and your driver is a 1394 driver, so I think
you need to assume you are at fault and work on reproducing the
failure with a summary kernel dump. mini-dumps are to me basically
useless.

Mark Roddy

On Thu, Mar 4, 2010 at 8:00 AM, stephan o’farrill
wrote:
> Hi All,
> I’ve received a customer crash report happing in conjunction with our
> 1394 device (WDM driver - without WDF). The mini dump itself does not
> contain any reference to our driver though.
> Is there anything I could test or check to know or exclude the
> involvements of our driver?
> Thanks for any idea or hint,
>
> Thanks,
> Hagen.
>
>
>
> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [O:\030310-12433-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is:
> srvc:\symbolshttp://msdl.microsoft.com/download/symbols;o:\objfre_wnet_amd64\amd64
> Executable search path is: o:\objfre_wnet_amd64\amd64
> Windows 7 Kernel Version 7600 MP (8 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
> Machine Name:
> Kernel base = 0xfffff80002a1d000 PsLoadedModuleList = 0xfffff80002c5ae50
> Debug session time: Wed Mar ?3 21:01:35.340 2010 (UTC + 1:00)
> System Uptime: 0 days 1:11:56.604
> Loading Kernel Symbols
> …
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
> *
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 12E, {fffffa8009cfee40, fffffa800a3c5a40, fffffa800a37d000, 800}
>
> Probably caused by : 1394BUS.SYS ( 1394BUS!Bus1394AsyncCompletionRoutine+b6 )
>
> Followup: MachineOwner
> ---------
>
> 1: kd> !analyze -v
> *
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>
>
> INVALID_MDL_RANGE (12e)
> A driver has called the IoBuildPartialMdl() function and passed it an MDL
> to map part of a source MDL, but the virtual address range specified is
> outside the range in the source MDL. ?This is a driver bug. ?The source
> and target MDLs, as well as the address range length to be mapped are the
> arguments to the IoBuildPartialMdl() function, i.e.;
> ? ?IoBuildPartialMdl(
> ? ? ? ?IN PMDL SourceMdl,
> ? ? ? ?IN OUT PMDL TargetMdl,
> ? ? ? ?IN PVOID VirtualAddress,
> ? ? ? ?IN ULONG Length
> ? ? ? ?)
> Arguments:
> Arg1: fffffa8009cfee40
> Arg2: fffffa800a3c5a40
> Arg3: fffffa800a37d000
> Arg4: 0000000000000800
>
> Debugging Details:
> ------------------
>
>
> CUSTOMER_CRASH_COUNT: ?1
>
> DEFAULT_BUCKET_ID: ?VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: ?0x12E
>
> PROCESS_NAME: ?System
>
> CURRENT_IRQL: ?2
>
> LAST_CONTROL_TRANSFER: ?from fffff80002ae41d6 to fffff80002a8ef00
>
> STACK_TEXT:
> fffff88002f1baa8 fffff80002ae41d6 : 000000000000012e > fffffa8009cfee40 fffffa800a3c5a40 fffffa800a37d000 :
> nt!KeBugCheckEx
> fffff88002f1bab0 fffff88005ccf6da : fffffa8009fd4958 > fffffa800a3c5a40 fffffa800b0cce50 0000000000000000 : nt! ??
> ::FNODOBFM::string'+0x2afc > fffff88002f1baf0 fffff80002a91516 : fffffa800b0ccf23
> 0000000000000000 fffffa800bd0eda0 fffff88005cd1b4d : > 1394BUS!Bus1394AsyncCompletionRoutine+0xb6 > fffff88002f1bb30 fffff88005cc32b4 : fffffa8009abab08
> fffffa8009ab9100 fffffa8009ab91a0 0000000000000000 : > nt!IopfCompleteRequest+0x3a6 > fffff88002f1bc10 fffff88005cc282e : 0000000000000001
> fffff88000000000 fffff880065483c0 fffff880009e7180 : > ohci1394!OhciHandleAsyncResponse+0x584 > fffff88002f1bc70 fffff80002a9a5dc : fffff880009e7180
> fffffa8009ab91a0 fffffa8009abaa50 0000000000000000 : > ohci1394!OhciDpc+0x3f6 > fffff88002f1bcd0 fffff80002a976fa : fffff880009e7180
> fffff880009f20c0 0000000000000000 fffff88005cc2438 : > nt!KiRetireDpcList+0x1bc > fffff88002f1bd80 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > nt!KiIdleLoop+0x5a > > > STACK_COMMAND: ?kb > > FOLLOWUP_IP: > 1394BUS!Bus1394AsyncCompletionRoutine+b6 > fffff88005ccf6da 8b8794000000 ? ?mov ? ? eax,dword ptr [rdi+94h]
>
> SYMBOL_STACK_INDEX: ?2
>
> SYMBOL_NAME: ?1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> FOLLOWUP_NAME: ?MachineOwner
>
> MODULE_NAME: 1394BUS
>
> IMAGE_NAME: ?1394BUS.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: ?4a5bcc0e
>
> FAILURE_BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> Followup: MachineOwner
> ---------
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Maxim_S_Shatskih · March 4, 2010, 2:39pm

I would switch the OS to legacy OHCI1394.SYS, the new Win7’s 1394 stack is buggy, but you can switch to legacy.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“stephan o’farrill” wrote in message news:xxxxx@ntdev…
> Hi All,
> I’ve received a customer crash report happing in conjunction with our
> 1394 device (WDM driver - without WDF). The mini dump itself does not
> contain any reference to our driver though.
> Is there anything I could test or check to know or exclude the
> involvements of our driver?
> Thanks for any idea or hint,
>
> Thanks,
> Hagen.
>
>
>
> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [O:\030310-12433-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is:
> srvc:\symbolshttp://msdl.microsoft.com/download/symbols;o:\objfre_wnet_amd64\amd64
> Executable search path is: o:\objfre_wnet_amd64\amd64
> Windows 7 Kernel Version 7600 MP (8 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
> Machine Name:
> Kernel base = 0xfffff80002a1d000 PsLoadedModuleList = 0xfffff80002c5ae50
> Debug session time: Wed Mar 3 21:01:35.340 2010 (UTC + 1:00)
> System Uptime: 0 days 1:11:56.604
> Loading Kernel Symbols
> …
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
> ***
> *
> * Bugcheck Analysis
> *
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 12E, {fffffa8009cfee40, fffffa800a3c5a40, fffffa800a37d000, 800}
>
> Probably caused by : 1394BUS.SYS ( 1394BUS!Bus1394AsyncCompletionRoutine+b6 )
>
> Followup: MachineOwner
> ---------
>
> 1: kd> !analyze -v
> ***
> *
> * Bugcheck Analysis
> *
>
>
> INVALID_MDL_RANGE (12e)
> A driver has called the IoBuildPartialMdl() function and passed it an MDL
> to map part of a source MDL, but the virtual address range specified is
> outside the range in the source MDL. This is a driver bug. The source
> and target MDLs, as well as the address range length to be mapped are the
> arguments to the IoBuildPartialMdl() function, i.e.;
> IoBuildPartialMdl(
> IN PMDL SourceMdl,
> IN OUT PMDL TargetMdl,
> IN PVOID VirtualAddress,
> IN ULONG Length
> )
> Arguments:
> Arg1: fffffa8009cfee40
> Arg2: fffffa800a3c5a40
> Arg3: fffffa800a37d000
> Arg4: 0000000000000800
>
> Debugging Details:
> ------------------
>
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0x12E
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 2
>
> LAST_CONTROL_TRANSFER: from fffff80002ae41d6 to fffff80002a8ef00
>
> STACK_TEXT:
> fffff88002f1baa8 fffff80002ae41d6 : 000000000000012e > fffffa8009cfee40 fffffa800a3c5a40 fffffa800a37d000 :
> nt!KeBugCheckEx
> fffff88002f1bab0 fffff88005ccf6da : fffffa8009fd4958 > fffffa800a3c5a40 fffffa800b0cce50 0000000000000000 : nt! ??
> ::FNODOBFM::string'+0x2afc > fffff88002f1baf0 fffff80002a91516 : fffffa800b0ccf23
> 0000000000000000 fffffa800bd0eda0 fffff88005cd1b4d : > 1394BUS!Bus1394AsyncCompletionRoutine+0xb6 > fffff88002f1bb30 fffff88005cc32b4 : fffffa8009abab08
> fffffa8009ab9100 fffffa8009ab91a0 0000000000000000 : > nt!IopfCompleteRequest+0x3a6 > fffff88002f1bc10 fffff88005cc282e : 0000000000000001
> fffff88000000000 fffff880065483c0 fffff880009e7180 : > ohci1394!OhciHandleAsyncResponse+0x584 > fffff88002f1bc70 fffff80002a9a5dc : fffff880009e7180
> fffffa8009ab91a0 fffffa8009abaa50 0000000000000000 : > ohci1394!OhciDpc+0x3f6 > fffff88002f1bcd0 fffff80002a976fa : fffff880009e7180
> fffff880009f20c0 0000000000000000 fffff88005cc2438 : > nt!KiRetireDpcList+0x1bc > fffff88002f1bd80 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > nt!KiIdleLoop+0x5a > > > STACK_COMMAND: kb > > FOLLOWUP_IP: > 1394BUS!Bus1394AsyncCompletionRoutine+b6 > fffff88005ccf6da 8b8794000000 mov eax,dword ptr [rdi+94h]
>
> SYMBOL_STACK_INDEX: 2
>
> SYMBOL_NAME: 1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: 1394BUS
>
> IMAGE_NAME: 1394BUS.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bcc0e
>
> FAILURE_BUCKET_ID: X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> BUCKET_ID: X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>
> Followup: MachineOwner
> ---------
>

OSR_Community_User · March 5, 2010, 1:42pm

Thanks Mark,
I am assuming its my fault, (although I know, there is another 1394
device on the bus, so there is hope I can shift the blame…)
But a summary kernel dump will not shed any more light in that issue,
as its probably the asynchronous bus answer for a call issued
earlier…

Best,
Hagen.

On Thu, Mar 4, 2010 at 7:30 PM, Mark Roddy wrote:
> It is in the 1394 stack and your driver is a 1394 driver, so I think
> you need to assume you are at fault and work on reproducing the
> failure with a summary kernel dump. mini-dumps are to me basically
> useless.
>
>
> Mark Roddy
>
>
>
> On Thu, Mar 4, 2010 at 8:00 AM, stephan o’farrill
> wrote:
>> Hi All,
>> I’ve received a customer crash report happing in conjunction with our
>> 1394 device (WDM driver - without WDF). The mini dump itself does not
>> contain any reference to our driver though.
>> Is there anything I could test or check to know or exclude the
>> involvements of our driver?
>> Thanks for any idea or hint,
>>
>> Thanks,
>> Hagen.
>>
>>
>>
>> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>
>>
>> Loading Dump File [O:\030310-12433-01.dmp]
>> Mini Kernel Dump File: Only registers and stack trace are available
>>
>> Symbol search path is:
>> srvc:\symbolshttp://msdl.microsoft.com/download/symbols;o:\objfre_wnet_amd64\amd64
>> Executable search path is: o:\objfre_wnet_amd64\amd64
>> Windows 7 Kernel Version 7600 MP (8 procs) Free x64
>> Product: WinNt, suite: TerminalServer SingleUserTS
>> Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
>> Machine Name:
>> Kernel base = 0xfffff80002a1d000 PsLoadedModuleList = 0xfffff80002c5ae50
>> Debug session time: Wed Mar ?3 21:01:35.340 2010 (UTC + 1:00)
>> System Uptime: 0 days 1:11:56.604
>> Loading Kernel Symbols
>> …
>> …
>> …
>> Loading User Symbols
>> Loading unloaded module list
>> …
>> *
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>>
>>
>> Use !analyze -v to get detailed debugging information.
>>
>> BugCheck 12E, {fffffa8009cfee40, fffffa800a3c5a40, fffffa800a37d000, 800}
>>
>> Probably caused by : 1394BUS.SYS ( 1394BUS!Bus1394AsyncCompletionRoutine+b6 )
>>
>> Followup: MachineOwner
>> ---------
>>
>> 1: kd> !analyze -v
>> *
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>>
>>
>> INVALID_MDL_RANGE (12e)
>> A driver has called the IoBuildPartialMdl() function and passed it an MDL
>> to map part of a source MDL, but the virtual address range specified is
>> outside the range in the source MDL. ?This is a driver bug. ?The source
>> and target MDLs, as well as the address range length to be mapped are the
>> arguments to the IoBuildPartialMdl() function, i.e.;
>> ? ?IoBuildPartialMdl(
>> ? ? ? ?IN PMDL SourceMdl,
>> ? ? ? ?IN OUT PMDL TargetMdl,
>> ? ? ? ?IN PVOID VirtualAddress,
>> ? ? ? ?IN ULONG Length
>> ? ? ? ?)
>> Arguments:
>> Arg1: fffffa8009cfee40
>> Arg2: fffffa800a3c5a40
>> Arg3: fffffa800a37d000
>> Arg4: 0000000000000800
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CUSTOMER_CRASH_COUNT: ?1
>>
>> DEFAULT_BUCKET_ID: ?VISTA_DRIVER_FAULT
>>
>> BUGCHECK_STR: ?0x12E
>>
>> PROCESS_NAME: ?System
>>
>> CURRENT_IRQL: ?2
>>
>> LAST_CONTROL_TRANSFER: ?from fffff80002ae41d6 to fffff80002a8ef00
>>
>> STACK_TEXT:
>> fffff88002f1baa8 fffff80002ae41d6 : 000000000000012e >> fffffa8009cfee40 fffffa800a3c5a40 fffffa800a37d000 :
>> nt!KeBugCheckEx
>> fffff88002f1bab0 fffff88005ccf6da : fffffa8009fd4958 >> fffffa800a3c5a40 fffffa800b0cce50 0000000000000000 : nt! ??
>> ::FNODOBFM::string'+0x2afc >> fffff88002f1baf0 fffff80002a91516 : fffffa800b0ccf23
>> 0000000000000000 fffffa800bd0eda0 fffff88005cd1b4d : >> 1394BUS!Bus1394AsyncCompletionRoutine+0xb6 >> fffff88002f1bb30 fffff88005cc32b4 : fffffa8009abab08
>> fffffa8009ab9100 fffffa8009ab91a0 0000000000000000 : >> nt!IopfCompleteRequest+0x3a6 >> fffff88002f1bc10 fffff88005cc282e : 0000000000000001
>> fffff88000000000 fffff880065483c0 fffff880009e7180 : >> ohci1394!OhciHandleAsyncResponse+0x584 >> fffff88002f1bc70 fffff80002a9a5dc : fffff880009e7180
>> fffffa8009ab91a0 fffffa8009abaa50 0000000000000000 : >> ohci1394!OhciDpc+0x3f6 >> fffff88002f1bcd0 fffff80002a976fa : fffff880009e7180
>> fffff880009f20c0 0000000000000000 fffff88005cc2438 : >> nt!KiRetireDpcList+0x1bc >> fffff88002f1bd80 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> nt!KiIdleLoop+0x5a >> >> >> STACK_COMMAND: ?kb >> >> FOLLOWUP_IP: >> 1394BUS!Bus1394AsyncCompletionRoutine+b6 >> fffff88005ccf6da 8b8794000000 ? ?mov ? ? eax,dword ptr [rdi+94h]
>>
>> SYMBOL_STACK_INDEX: ?2
>>
>> SYMBOL_NAME: ?1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> FOLLOWUP_NAME: ?MachineOwner
>>
>> MODULE_NAME: 1394BUS
>>
>> IMAGE_NAME: ?1394BUS.SYS
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: ?4a5bcc0e
>>
>> FAILURE_BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> Followup: MachineOwner
>> ---------
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–
___________________
dynamic acoustics e.U.
Weyringergasse 37/3/11a
1040 Vienna / Austria
+43 680 1268 751

VAT: ATU65049413
FN: 326751t
IBAN: AT463200000010353811
BIC: RLNWATWW

OSR_Community_User · March 5, 2010, 1:43pm

Thanks Maxim,
it happened with the legacy driver, the customer reported that it
wouldn’t work at all with the w7 driver.

Best,
Hagen.

On Thu, Mar 4, 2010 at 8:39 PM, Maxim S. Shatskih
wrote:
> ? ?I would switch the OS to legacy OHCI1394.SYS, the new Win7’s 1394 stack is buggy, but you can switch to legacy.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “stephan o’farrill” wrote in message news:xxxxx@ntdev…
>> Hi All,
>> I’ve received a customer crash report happing in conjunction with our
>> 1394 device (WDM driver - without WDF). The mini dump itself does not
>> contain any reference to our driver though.
>> Is there anything I could test or check to know or exclude the
>> involvements of our driver?
>> Thanks for any idea or hint,
>>
>> Thanks,
>> Hagen.
>>
>>
>>
>> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>
>>
>> Loading Dump File [O:\030310-12433-01.dmp]
>> Mini Kernel Dump File: Only registers and stack trace are available
>>
>> Symbol search path is:
>> srvc:\symbolshttp://msdl.microsoft.com/download/symbols;o:\objfre_wnet_amd64\amd64
>> Executable search path is: o:\objfre_wnet_amd64\amd64
>> Windows 7 Kernel Version 7600 MP (8 procs) Free x64
>> Product: WinNt, suite: TerminalServer SingleUserTS
>> Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
>> Machine Name:
>> Kernel base = 0xfffff80002a1d000 PsLoadedModuleList = 0xfffff80002c5ae50
>> Debug session time: Wed Mar ?3 21:01:35.340 2010 (UTC + 1:00)
>> System Uptime: 0 days 1:11:56.604
>> Loading Kernel Symbols
>> …
>> …
>> …
>> Loading User Symbols
>> Loading unloaded module list
>> …
>> *
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>>
>>
>> Use !analyze -v to get detailed debugging information.
>>
>> BugCheck 12E, {fffffa8009cfee40, fffffa800a3c5a40, fffffa800a37d000, 800}
>>
>> Probably caused by : 1394BUS.SYS ( 1394BUS!Bus1394AsyncCompletionRoutine+b6 )
>>
>> Followup: MachineOwner
>> ---------
>>
>> 1: kd> !analyze -v
>> *
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>>
>>
>> INVALID_MDL_RANGE (12e)
>> A driver has called the IoBuildPartialMdl() function and passed it an MDL
>> to map part of a source MDL, but the virtual address range specified is
>> outside the range in the source MDL. ?This is a driver bug. ?The source
>> and target MDLs, as well as the address range length to be mapped are the
>> arguments to the IoBuildPartialMdl() function, i.e.;
>> ? ?IoBuildPartialMdl(
>> ? ? ? ?IN PMDL SourceMdl,
>> ? ? ? ?IN OUT PMDL TargetMdl,
>> ? ? ? ?IN PVOID VirtualAddress,
>> ? ? ? ?IN ULONG Length
>> ? ? ? ?)
>> Arguments:
>> Arg1: fffffa8009cfee40
>> Arg2: fffffa800a3c5a40
>> Arg3: fffffa800a37d000
>> Arg4: 0000000000000800
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CUSTOMER_CRASH_COUNT: ?1
>>
>> DEFAULT_BUCKET_ID: ?VISTA_DRIVER_FAULT
>>
>> BUGCHECK_STR: ?0x12E
>>
>> PROCESS_NAME: ?System
>>
>> CURRENT_IRQL: ?2
>>
>> LAST_CONTROL_TRANSFER: ?from fffff80002ae41d6 to fffff80002a8ef00
>>
>> STACK_TEXT:
>> fffff88002f1baa8 fffff80002ae41d6 : 000000000000012e >> fffffa8009cfee40 fffffa800a3c5a40 fffffa800a37d000 :
>> nt!KeBugCheckEx
>> fffff88002f1bab0 fffff88005ccf6da : fffffa8009fd4958 >> fffffa800a3c5a40 fffffa800b0cce50 0000000000000000 : nt! ??
>> ::FNODOBFM::string'+0x2afc >> fffff88002f1baf0 fffff80002a91516 : fffffa800b0ccf23
>> 0000000000000000 fffffa800bd0eda0 fffff88005cd1b4d : >> 1394BUS!Bus1394AsyncCompletionRoutine+0xb6 >> fffff88002f1bb30 fffff88005cc32b4 : fffffa8009abab08
>> fffffa8009ab9100 fffffa8009ab91a0 0000000000000000 : >> nt!IopfCompleteRequest+0x3a6 >> fffff88002f1bc10 fffff88005cc282e : 0000000000000001
>> fffff88000000000 fffff880065483c0 fffff880009e7180 : >> ohci1394!OhciHandleAsyncResponse+0x584 >> fffff88002f1bc70 fffff80002a9a5dc : fffff880009e7180
>> fffffa8009ab91a0 fffffa8009abaa50 0000000000000000 : >> ohci1394!OhciDpc+0x3f6 >> fffff88002f1bcd0 fffff80002a976fa : fffff880009e7180
>> fffff880009f20c0 0000000000000000 fffff88005cc2438 : >> nt!KiRetireDpcList+0x1bc >> fffff88002f1bd80 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> nt!KiIdleLoop+0x5a >> >> >> STACK_COMMAND: ?kb >> >> FOLLOWUP_IP: >> 1394BUS!Bus1394AsyncCompletionRoutine+b6 >> fffff88005ccf6da 8b8794000000 ? ?mov ? ? eax,dword ptr [rdi+94h]
>>
>> SYMBOL_STACK_INDEX: ?2
>>
>> SYMBOL_NAME: ?1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> FOLLOWUP_NAME: ?MachineOwner
>>
>> MODULE_NAME: 1394BUS
>>
>> IMAGE_NAME: ?1394BUS.SYS
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: ?4a5bcc0e
>>
>> FAILURE_BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> BUCKET_ID: ?X64_0x12E_1394BUS!Bus1394AsyncCompletionRoutine+b6
>>
>> Followup: MachineOwner
>> ---------
>>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–
___________________
dynamic acoustics e.U.
Weyringergasse 37/3/11a
1040 Vienna / Austria
+43 680 1268 751

VAT: ATU65049413
FN: 326751t
IBAN: AT463200000010353811
BIC: RLNWATWW

anton_bassov · March 6, 2010, 5:49am

> The mini dump itself does not contain any reference to our driver though.

…which means that you may be dealing with a particularly nasty bug (like, for example, corrupting memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it may still have interops wth “not-so-well- written” drivers…

The only solution in situation like that seems to be a thorough code review…

Anton Bassov

OSR_Community_User · March 6, 2010, 6:21am

Thanks, Anton,
thats right. And to make things even worse this thing rarely happens
on a particular customer installation and of-course never on my
development machine…
Best,
Hagen.

On Sat, Mar 6, 2010 at 11:48 AM, wrote:
>> The mini dump itself does not contain any reference to our driver though.
>
>
> …which means that you may be dealing with a particularly nasty bug (like, for example, corrupting ?memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it ?may still have interops wth “not-so-well- written” drivers…
>
> The only solution in situation like that seems to be a thorough code review…
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–
___________________
dynamic acoustics e.U.
Weyringergasse 37/3/11a
1040 Vienna / Austria
+43 680 1268 751

VAT: ATU65049413
FN: 326751t
IBAN: AT463200000010353811
BIC: RLNWATWW

Mark_Roddy · March 6, 2010, 10:41am

Runtime trace information from your driver (and anyone else who has a
trace log) can help identify what the sequence of events are that
result in the malfunction.

Mark Roddy

On Sat, Mar 6, 2010 at 6:21 AM, stephan o’farrill
wrote:
> Thanks, Anton,
> thats right. And to make things even worse this thing rarely happens
> on a particular customer installation and of-course never on my
> development machine…
> Best,
> Hagen.
>
> On Sat, Mar 6, 2010 at 11:48 AM, ? wrote:
>>> The mini dump itself does not contain any reference to our driver though.
>>
>>
>> …which means that you may be dealing with a particularly nasty bug (like, for example, corrupting ?memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it ?may still have interops wth “not-so-well- written” drivers…
>>
>> The only solution in situation like that seems to be a thorough code review…
>>
>>
>> Anton Bassov
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>
>
>
> –
> ___________________
> dynamic acoustics e.U.
> Weyringergasse 37/3/11a
> 1040 Vienna / Austria
> +43 680 1268 751
>
> VAT: ATU65049413
> FN: 326751t
> IBAN: AT463200000010353811
> BIC: RLNWATWW
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

OSR_Community_User · March 6, 2010, 12:53pm

Thanks Mark,
tracing at that level for a production driver is usually disabled. But
yes, its an option (but may change some timing and “fixing” it that
way…)
The other pitfall is if the log makes it to disk at all before the
faulting asynchronous response comes in…
Best,
Hagen.

On Sat, Mar 6, 2010 at 4:40 PM, Mark Roddy wrote:
> Runtime trace information from your driver (and anyone else who has a
> trace log) can help identify what the sequence of events are that
> result in the malfunction.
>
> Mark Roddy
>
>
>
> On Sat, Mar 6, 2010 at 6:21 AM, stephan o’farrill
> wrote:
>> Thanks, Anton,
>> thats right. And to make things even worse this thing rarely happens
>> on a particular customer installation and of-course never on my
>> development machine…
>> Best,
>> Hagen.
>>
>> On Sat, Mar 6, 2010 at 11:48 AM, ? wrote:
>>>> The mini dump itself does not contain any reference to our driver though.
>>>
>>>
>>> …which means that you may be dealing with a particularly nasty bug (like, for example, corrupting ?memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it ?may still have interops wth “not-so-well- written” drivers…
>>>
>>> The only solution in situation like that seems to be a thorough code review…
>>>
>>>
>>> Anton Bassov
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> 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
>>>
>>
>>
>>
>> –
>> ___________________
>> dynamic acoustics e.U.
>> Weyringergasse 37/3/11a
>> 1040 Vienna / Austria
>> +43 680 1268 751
>>
>> VAT: ATU65049413
>> FN: 326751t
>> IBAN: AT463200000010353811
>> BIC: RLNWATWW
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Velio_Roumenov-2 · March 7, 2010, 3:53am

If you are using WPP software tracing in your driver you can get the
logs in to the dump file.

WPP Software tracing: http://msdn.microsoft.com/en-us/library/ms793164.aspx
Autologger: http://msdn.microsoft.com/en-us/library/ms797180.aspx

Also it seems as if you can enable logging on the MS 1394 stack as
well, haven’t read through it but there is a blog entry about it at
http://blogs.msdn.com/usbcoreblog/archive/2010/02/10/how-to-generate-and-view-a-1394-debug-log.aspx

Faik

On Sat, Mar 6, 2010 at 6:52 PM, stephan o’farrill
wrote:
> Thanks Mark,
> tracing at that level for a production driver is usually disabled. But
> yes, its an option (but may change some timing and “fixing” it that
> way…)
> The other pitfall is if the log makes it to disk at all before the
> faulting asynchronous response comes in…
> Best,
> Hagen.
>
> On Sat, Mar 6, 2010 at 4:40 PM, Mark Roddy wrote:
>> Runtime trace information from your driver (and anyone else who has a
>> trace log) can help identify what the sequence of events are that
>> result in the malfunction.
>>
>> Mark Roddy
>>
>>
>>
>> On Sat, Mar 6, 2010 at 6:21 AM, stephan o’farrill
>> wrote:
>>> Thanks, Anton,
>>> thats right. And to make things even worse this thing rarely happens
>>> on a particular customer installation and of-course never on my
>>> development machine…
>>> Best,
>>> Hagen.
>>>
>>> On Sat, Mar 6, 2010 at 11:48 AM, ? wrote:
>>>>> The mini dump itself does not contain any reference to our driver though.
>>>>
>>>>
>>>> …which means that you may be dealing with a particularly nasty bug (like, for example, corrupting ?memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it ?may still have interops wth “not-so-well- written” drivers…
>>>>
>>>> The only solution in situation like that seems to be a thorough code review…
>>>>
>>>>
>>>> Anton Bassov
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> 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
>>>>
>>>
>>>
>>>
>>> –
>>> ___________________
>>> dynamic acoustics e.U.
>>> Weyringergasse 37/3/11a
>>> 1040 Vienna / Austria
>>> +43 680 1268 751
>>>
>>> VAT: ATU65049413
>>> FN: 326751t
>>> IBAN: AT463200000010353811
>>> BIC: RLNWATWW
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> 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
>>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Mark_Roddy · March 8, 2010, 9:32am

And really what other options are there at this point? Yes of course tracing
can alter timing - but not all that much when the trace output is simply
going into a buffer.

Mark Roddy

On Sun, Mar 7, 2010 at 3:52 AM, Faik Riza wrote:

> If you are using WPP software tracing in your driver you can get the
> logs in to the dump file.
>
> WPP Software tracing:
> http://msdn.microsoft.com/en-us/library/ms793164.aspx
> Autologger: http://msdn.microsoft.com/en-us/library/ms797180.aspx
>
> Also it seems as if you can enable logging on the MS 1394 stack as
> well, haven’t read through it but there is a blog entry about it at
>
> http://blogs.msdn.com/usbcoreblog/archive/2010/02/10/how-to-generate-and-view-a-1394-debug-log.aspx
>
> Faik
>
> On Sat, Mar 6, 2010 at 6:52 PM, stephan o’farrill
> wrote:
> > Thanks Mark,
> > tracing at that level for a production driver is usually disabled. But
> > yes, its an option (but may change some timing and “fixing” it that
> > way…)
> > The other pitfall is if the log makes it to disk at all before the
> > faulting asynchronous response comes in…
> > Best,
> > Hagen.
> >
> > On Sat, Mar 6, 2010 at 4:40 PM, Mark Roddy wrote:
> >> Runtime trace information from your driver (and anyone else who has a
> >> trace log) can help identify what the sequence of events are that
> >> result in the malfunction.
> >>
> >> Mark Roddy
> >>
> >>
> >>
> >> On Sat, Mar 6, 2010 at 6:21 AM, stephan o’farrill
> >> wrote:
> >>> Thanks, Anton,
> >>> thats right. And to make things even worse this thing rarely happens
> >>> on a particular customer installation and of-course never on my
> >>> development machine…
> >>> Best,
> >>> Hagen.
> >>>
> >>> On Sat, Mar 6, 2010 at 11:48 AM, wrote:
> >>>>> The mini dump itself does not contain any reference to our driver
> though.
> >>>>
> >>>>
> >>>> …which means that you may be dealing with a particularly nasty bug
> (like, for example, corrupting memory) that does not reveal on the spot. To
> make things even worse, it looks pretty much like “it takes two to tango”
> -style bug - although it would never reveal itself in a stack where all
> participants are “perfect” it may still have interops wth “not-so-well-
> written” drivers…
> >>>>
> >>>> The only solution in situation like that seems to be a thorough code
> review…
> >>>>
> >>>>
> >>>> Anton Bassov
> >>>>
> >>>> —
> >>>> NTDEV is sponsored by OSR
> >>>>
> >>>> 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
> >>>>
> >>>
> >>>
> >>>
> >>> –
> >>> ___________________
> >>> dynamic acoustics e.U.
> >>> Weyringergasse 37/3/11a
> >>> 1040 Vienna / Austria
> >>> +43 680 1268 751
> >>>
> >>> VAT: ATU65049413
> >>> FN: 326751t
> >>> IBAN: AT463200000010353811
> >>> BIC: RLNWATWW
> >>>
> >>> —
> >>> NTDEV is sponsored by OSR
> >>>
> >>> 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
> >>>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> 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
> >>
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > 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
> >
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

OSR_Community_User · March 8, 2010, 9:52am

Thanks, Falk,
for pointing that out! I am looking into these options.

Best,
Hagen.

On Sun, Mar 7, 2010 at 9:52 AM, Faik Riza wrote:
> If you are using WPP software tracing in your driver you can get the
> logs in to the dump file.
>
> WPP Software tracing: http://msdn.microsoft.com/en-us/library/ms793164.aspx
> Autologger: http://msdn.microsoft.com/en-us/library/ms797180.aspx
>
> Also it seems as if you can enable logging on the MS 1394 stack as
> well, haven’t read through it but there is a blog entry about it at
> http://blogs.msdn.com/usbcoreblog/archive/2010/02/10/how-to-generate-and-view-a-1394-debug-log.aspx
>
> Faik
>
> On Sat, Mar 6, 2010 at 6:52 PM, stephan o’farrill
> wrote:
>> Thanks Mark,
>> tracing at that level for a production driver is usually disabled. But
>> yes, its an option (but may change some timing and “fixing” it that
>> way…)
>> The other pitfall is if the log makes it to disk at all before the
>> faulting asynchronous response comes in…
>> Best,
>> Hagen.
>>
>> On Sat, Mar 6, 2010 at 4:40 PM, Mark Roddy wrote:
>>> Runtime trace information from your driver (and anyone else who has a
>>> trace log) can help identify what the sequence of events are that
>>> result in the malfunction.
>>>
>>> Mark Roddy
>>>
>>>
>>>
>>> On Sat, Mar 6, 2010 at 6:21 AM, stephan o’farrill
>>> wrote:
>>>> Thanks, Anton,
>>>> thats right. And to make things even worse this thing rarely happens
>>>> on a particular customer installation and of-course never on my
>>>> development machine…
>>>> Best,
>>>> Hagen.
>>>>
>>>> On Sat, Mar 6, 2010 at 11:48 AM, ? wrote:
>>>>>> The mini dump itself does not contain any reference to our driver though.
>>>>>
>>>>>
>>>>> …which means that you may be dealing with a particularly nasty bug (like, for example, corrupting ?memory) that does not reveal on the spot. To make things even worse, it looks pretty much like “it takes two to tango” -style bug - although it would never reveal itself in a stack where all participants are “perfect” it ?may still have interops wth “not-so-well- written” drivers…
>>>>>
>>>>> The only solution in situation like that seems to be a thorough code review…
>>>>>
>>>>>
>>>>> Anton Bassov
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> –
>>>>
>>>> dynamic acoustics e.U.
>>>> Weyringergasse 37/3/11a
>>>> 1040 Vienna / Austria
>>>> +43 680 1268 751
>>>>
>>>> VAT: ATU65049413
>>>> FN: 326751t
>>>> IBAN: AT463200000010353811
>>>> BIC: RLNWATWW
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> 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
>>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> 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
>>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

dynamic acoustics e.U.
Weyringergasse 37/3/11a
1040 Vienna / Austria
+43 680 1268 751

VAT: ATU65049413
FN: 326751t
IBAN: AT463200000010353811
BIC: RLNWATWW