Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as USB
audio device. Everything is normal and working good. When I get a request
from USB audio driver ( Microsoft ) , if it need to be send down then I will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system crashes
with the above error. Instead of calling next level driver with a new IRP ,
somehow it ends with the IRP that came originally although I never send it
when this error happens. If the allocation of IRP fails , we will return the
error to the top layer and that does not happen. The error in debugger is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came from
USB audio driver to next layer. How can I ensure it does have enough stack
locations.

Even though I am checking for stack size before sending the request down it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

What does the call stack look like when you bugcheck? Also, which sp
number is installed on win2k?

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still
from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the
Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows
anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as
USB
audio device. Everything is normal and working good. When I get a
request
from USB audio driver ( Microsoft ) , if it need to be send down then I
will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system
crashes
with the above error. Instead of calling next level driver with a new
IRP ,
somehow it ends with the IRP that came originally although I never send
it
when this error happens. If the allocation of IRP fails , we will return
the
error to the top layer and that does not happen. The error in debugger
is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came
from
USB audio driver to next layer. How can I ensure it does have enough
stack
locations.

Even though I am checking for stack size before sending the request down
it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows
XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi doron

Thank you very much for the reply.

It is windows 2000 , sp 1.

call stack looks as follows when it bugchecked:

PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Ejection Relations
PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Removal Relations

FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
FDO In RemovalRelations
FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
FDO In EjectionRelations

*** Fatal System Error: 0x00000035
(0xBDED9F68,0x00000000,0x00000000,0x00000000)

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 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols


Loading unloaded module list

Loading User Symbols

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

Use !analyze -v to get detailed debugging information.

BugCheck 35, {bded9f68, 0, 0, 0}

*** WARNING: Unable to verify checksum for VoIPAppsc.exe
*** ERROR: Module load completed but symbols could not be loaded for
VoIPAppsc.exe
Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80453d52 cc int 3
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver “thinks” it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: bded9f68, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x35

LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52

STACK_TEXT:
e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
nt!RtlpBreakWithStatusInstruction
e7fc2170 8042c1c1 00000003 82cff5b0 00000000 nt!KiBugCheckDebugBreak+0x31
e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
e7fc2554 e7f34f54 00000103 00000001 826581d0 nt!IovSpecialIrpCallDriver+0x9f
e7fc256c e7f353d9 80ea7b08 00000003 826581d0
usbaudio!StartIsocInputTransfer+0x64
e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
usbaudio!CaptureStateChange+0xb9
e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
usbaudio!AudioReceiveCtrlPacket+0x3e
e7fc25dc e80bca18 84f95900 82658008 80ea7b08
STREAM!SCIssueRequestToDevice+0xad
e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08 STREAM!SCStreamDeviceState+0x8c
e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
STREAM!StreamDispatchIoControl+0x228
e7fc2780 8052d790 84f95890 bf81ff48 84f95890 KS!DispatchDeviceIoControl+0x2a
e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574 nt!IovSpecialIrpCallDriver+0xcd
e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2840 eb255bb5 82b4ac48 00000000 00000002
sysaudio!PinConnectionProperty+0x40
e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
e7fc288c eb255f47 00000002 00000003 00000002 sysaudio!SetStateTopDown+0x2a
e7fc28b0 eb255af4 e14fdd30 00000003 00000006
sysaudio!SetPinInstanceState+0x43
e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48 sysaudio!PinStateHandler+0x55
e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
sysaudio!PinDispatchIoControl+0x145
e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850 KS!DispatchDeviceIoControl+0x2a
e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8 nt!IovSpecialIrpCallDriver+0xcd
e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
e7fc2c20 80498d61 865726ce 00000000 bf819f48 nt!IovSpecialIrpCallDriver+0xcd
e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
nt!IopSynchronousServiceTail+0x60
e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
e7fc2d34 80462cf1 000000d0 000001e4 00000000 nt!NtDeviceIoControlFile+0x28
e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
00c0fd38 77e886a3 000000d0 000001e4 00000000 ntdll!NtDeviceIoControlFile+0xb
00c0fd9c 77563e73 000000d0 001d8144 0013f6c8 KERNEL32!DeviceIoControl+0x93
00c0fde8 77561524 0013f6c8 00000000 00000000
wdmaud_77560000!wdmaudIoControl+0x93
00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
wdmaud_77560000!wdmaudSetDeviceState+0x6d
00c0fe28 77561b28 0013f6c8 00000000 002f8f10 wdmaud_77560000!waveWrite+0xa8
00c0fe44 77577dc6 00000000 00000038 0013f6c8
wdmaud_77560000!widMessage+0x10e
00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970

FOLLOWUP_IP:
usbaudio!StartIsocInputTransfer+64
e7f34f54 8945f0 mov [ebp-0x10],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64

MODULE_NAME: usbaudio

IMAGE_NAME: usbaudio.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4

STACK_COMMAND: kb

BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64

Followup: MachineOwner

This problem occurs even with some standard USB Audio device.

When there is no bug check the call stack trace as follows :

STACK_TEXT:
eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
eb42f488 e80587bb 80253030 b5c5ff68 80253030
voipbd!IsoSendRequestToUsb+0x27b [e:\voip\drivers\voipbusdriver\ctrlurb.cpp
@ 2832]
eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
eb42f610 8052d790 80253030 b5c5ff68 00000000
voipbd!MTVoIP_InternalDispatchControl+0x26
[e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
eb42f65c e8040d95 00000000 ffdff120 00000000 nt!IovSpecialIrpCallDriver+0xcd
eb42f680 e8042354 80253030 87433628 00000010 usbaudio!PCM2USB_CallUSBD+0xa5
eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
usbaudio!PCM2USB_WriteReset+0x64
eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
usbaudio!AdapterOpenStream+0x458
eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
usbaudio!AdapterReceivePacket+0x2a
eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
STREAM!SCIssueRequestToDevice+0xad
eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
STREAM!StreamDispatchCreate+0x220
eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c nt!IovSpecialIrpCallDriver+0xcd
eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
sysaudio!CreatePinNodeInstance+0xbb
eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
sysaudio!CreateConnectNodeInstance+0x11e
eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
sysaudio!CreateStartNodeInstance+0x9b
eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
sysaudio!PinDispatchCreateKP+0x8f
eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
sysaudio!CallKernelProcessWorker+0xe
eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The voipbd is our driver .

Let me know if you need any more information.

thanks in advance
sri.

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, March 05, 2003 4:15 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

What does the call stack look like when you bugcheck? Also, which sp
number is installed on win2k?

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still
from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the
Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows
anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as
USB
audio device. Everything is normal and working good. When I get a
request
from USB audio driver ( Microsoft ) , if it need to be send down then I
will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system
crashes
with the above error. Instead of calling next level driver with a new
IRP ,
somehow it ends with the IRP that came originally although I never send
it
when this error happens. If the allocation of IRP fails , we will return
the
error to the top layer and that does not happen. The error in debugger
is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came
from
USB audio driver to next layer. How can I ensure it does have enough
stack
locations.

Even though I am checking for stack size before sending the request down
it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows
XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi doron

the information what I gave is insufficient to find any clue of what is
wrong ?

Thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 4:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

Hi doron

Thank you very much for the reply.

It is windows 2000 , sp 1.

call stack looks as follows when it bugchecked:

PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Ejection Relations
PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Removal Relations

FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
FDO In RemovalRelations
FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
FDO In EjectionRelations

*** Fatal System Error: 0x00000035
(0xBDED9F68,0x00000000,0x00000000,0x00000000)

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 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols


Loading unloaded module list

Loading User Symbols

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

Use !analyze -v to get detailed debugging information.

BugCheck 35, {bded9f68, 0, 0, 0}

*** WARNING: Unable to verify checksum for VoIPAppsc.exe
*** ERROR: Module load completed but symbols could not be loaded for
VoIPAppsc.exe
Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80453d52 cc int 3
kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver “thinks” it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: bded9f68, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x35

LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52

STACK_TEXT:
e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
nt!RtlpBreakWithStatusInstruction
e7fc2170 8042c1c1 00000003 82cff5b0 00000000 nt!KiBugCheckDebugBreak+0x31
e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
e7fc2554 e7f34f54 00000103 00000001 826581d0 nt!IovSpecialIrpCallDriver+0x9f
e7fc256c e7f353d9 80ea7b08 00000003 826581d0
usbaudio!StartIsocInputTransfer+0x64
e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
usbaudio!CaptureStateChange+0xb9
e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
usbaudio!AudioReceiveCtrlPacket+0x3e
e7fc25dc e80bca18 84f95900 82658008 80ea7b08
STREAM!SCIssueRequestToDevice+0xad
e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08 STREAM!SCStreamDeviceState+0x8c
e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
STREAM!StreamDispatchIoControl+0x228
e7fc2780 8052d790 84f95890 bf81ff48 84f95890 KS!DispatchDeviceIoControl+0x2a
e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574 nt!IovSpecialIrpCallDriver+0xcd
e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2840 eb255bb5 82b4ac48 00000000 00000002
sysaudio!PinConnectionProperty+0x40
e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
e7fc288c eb255f47 00000002 00000003 00000002 sysaudio!SetStateTopDown+0x2a
e7fc28b0 eb255af4 e14fdd30 00000003 00000006
sysaudio!SetPinInstanceState+0x43
e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48 sysaudio!PinStateHandler+0x55
e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
sysaudio!PinDispatchIoControl+0x145
e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850 KS!DispatchDeviceIoControl+0x2a
e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8 nt!IovSpecialIrpCallDriver+0xcd
e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
e7fc2c20 80498d61 865726ce 00000000 bf819f48 nt!IovSpecialIrpCallDriver+0xcd
e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
nt!IopSynchronousServiceTail+0x60
e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
e7fc2d34 80462cf1 000000d0 000001e4 00000000 nt!NtDeviceIoControlFile+0x28
e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
00c0fd38 77e886a3 000000d0 000001e4 00000000 ntdll!NtDeviceIoControlFile+0xb
00c0fd9c 77563e73 000000d0 001d8144 0013f6c8 KERNEL32!DeviceIoControl+0x93
00c0fde8 77561524 0013f6c8 00000000 00000000
wdmaud_77560000!wdmaudIoControl+0x93
00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
wdmaud_77560000!wdmaudSetDeviceState+0x6d
00c0fe28 77561b28 0013f6c8 00000000 002f8f10 wdmaud_77560000!waveWrite+0xa8
00c0fe44 77577dc6 00000000 00000038 0013f6c8
wdmaud_77560000!widMessage+0x10e
00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970

FOLLOWUP_IP:
usbaudio!StartIsocInputTransfer+64
e7f34f54 8945f0 mov [ebp-0x10],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64

MODULE_NAME: usbaudio

IMAGE_NAME: usbaudio.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4

STACK_COMMAND: kb

BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64

Followup: MachineOwner

This problem occurs even with some standard USB Audio device.

When there is no bug check the call stack trace as follows :

STACK_TEXT:
eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
eb42f488 e80587bb 80253030 b5c5ff68 80253030
voipbd!IsoSendRequestToUsb+0x27b [e:\voip\drivers\voipbusdriver\ctrlurb.cpp
@ 2832]
eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
eb42f610 8052d790 80253030 b5c5ff68 00000000
voipbd!MTVoIP_InternalDispatchControl+0x26
[e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
eb42f65c e8040d95 00000000 ffdff120 00000000 nt!IovSpecialIrpCallDriver+0xcd
eb42f680 e8042354 80253030 87433628 00000010 usbaudio!PCM2USB_CallUSBD+0xa5
eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
usbaudio!PCM2USB_WriteReset+0x64
eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
usbaudio!AdapterOpenStream+0x458
eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
usbaudio!AdapterReceivePacket+0x2a
eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
STREAM!SCIssueRequestToDevice+0xad
eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
STREAM!StreamDispatchCreate+0x220
eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c nt!IovSpecialIrpCallDriver+0xcd
eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
sysaudio!CreatePinNodeInstance+0xbb
eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
sysaudio!CreateConnectNodeInstance+0x11e
eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
sysaudio!CreateStartNodeInstance+0x9b
eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
sysaudio!PinDispatchCreateKP+0x8f
eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
sysaudio!CallKernelProcessWorker+0xe
eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The voipbd is our driver .

Let me know if you need any more information.

thanks in advance
sri.

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, March 05, 2003 4:15 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

What does the call stack look like when you bugcheck? Also, which sp
number is installed on win2k?

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still
from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the
Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows
anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as
USB
audio device. Everything is normal and working good. When I get a
request
from USB audio driver ( Microsoft ) , if it need to be send down then I
will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system
crashes
with the above error. Instead of calling next level driver with a new
IRP ,
somehow it ends with the IRP that came originally although I never send
it
when this error happens. If the allocation of IRP fails , we will return
the
error to the top layer and that does not happen. The error in debugger
is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came
from
USB audio driver to next layer. How can I ensure it does have enough
stack
locations.

Even though I am checking for stack size before sending the request down
it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows
XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I am trying to find enough time to look at the problem, I am currently
inundated with higher priority work. I will try to look at this by EOD
today.

D

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Friday, March 07, 2003 9:39 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

Hi doron

the information what I gave is insufficient to find any clue of what is
wrong ?

Thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 4:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

Hi doron

Thank you very much for the reply.

It is windows 2000 , sp 1.

call stack looks as follows when it bugchecked:

PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Ejection Relations
PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Removal Relations

FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS

FDO In RemovalRelations
FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS

FDO In EjectionRelations

*** Fatal System Error: 0x00000035
(0xBDED9F68,0x00000000,0x00000000,0x00000000)

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 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols



Loading unloaded module list

Loading User Symbols

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

Use !analyze -v to get detailed debugging information.

BugCheck 35, {bded9f68, 0, 0, 0}

*** WARNING: Unable to verify checksum for VoIPAppsc.exe
*** ERROR: Module load completed but symbols could not be loaded for
VoIPAppsc.exe
Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80453d52 cc int 3
kd> !analyze -v
************************************************************************
****
***
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
****
***

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in
the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver “thinks” it has filled in the
parameters for the lower level driver (something it MUST do before it
calls
it), but since there is no stack location for the latter driver, the
former
has written off of the end of the packet. This means that some other
memory
has probably been trashed at this point.
Arguments:
Arg1: bded9f68, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x35

LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52

STACK_TEXT:
e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
nt!RtlpBreakWithStatusInstruction
e7fc2170 8042c1c1 00000003 82cff5b0 00000000
nt!KiBugCheckDebugBreak+0x31
e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
e7fc2554 e7f34f54 00000103 00000001 826581d0
nt!IovSpecialIrpCallDriver+0x9f
e7fc256c e7f353d9 80ea7b08 00000003 826581d0
usbaudio!StartIsocInputTransfer+0x64
e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
usbaudio!CaptureStateChange+0xb9
e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
usbaudio!AudioReceiveCtrlPacket+0x3e
e7fc25dc e80bca18 84f95900 82658008 80ea7b08
STREAM!SCIssueRequestToDevice+0xad
e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08
STREAM!SCStreamDeviceState+0x8c
e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
STREAM!StreamDispatchIoControl+0x228
e7fc2780 8052d790 84f95890 bf81ff48 84f95890
KS!DispatchDeviceIoControl+0x2a
e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574
nt!IovSpecialIrpCallDriver+0xcd
e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2840 eb255bb5 82b4ac48 00000000 00000002
sysaudio!PinConnectionProperty+0x40
e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
e7fc288c eb255f47 00000002 00000003 00000002
sysaudio!SetStateTopDown+0x2a
e7fc28b0 eb255af4 e14fdd30 00000003 00000006
sysaudio!SetPinInstanceState+0x43
e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48
sysaudio!PinStateHandler+0x55
e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
sysaudio!PinDispatchIoControl+0x145
e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850
KS!DispatchDeviceIoControl+0x2a
e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8
nt!IovSpecialIrpCallDriver+0xcd
e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
e7fc2c20 80498d61 865726ce 00000000 bf819f48
nt!IovSpecialIrpCallDriver+0xcd
e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
nt!IopSynchronousServiceTail+0x60
e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
e7fc2d34 80462cf1 000000d0 000001e4 00000000
nt!NtDeviceIoControlFile+0x28
e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
00c0fd38 77e886a3 000000d0 000001e4 00000000
ntdll!NtDeviceIoControlFile+0xb
00c0fd9c 77563e73 000000d0 001d8144 0013f6c8
KERNEL32!DeviceIoControl+0x93
00c0fde8 77561524 0013f6c8 00000000 00000000
wdmaud_77560000!wdmaudIoControl+0x93
00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
wdmaud_77560000!wdmaudSetDeviceState+0x6d
00c0fe28 77561b28 0013f6c8 00000000 002f8f10
wdmaud_77560000!waveWrite+0xa8
00c0fe44 77577dc6 00000000 00000038 0013f6c8
wdmaud_77560000!widMessage+0x10e
00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970

FOLLOWUP_IP:
usbaudio!StartIsocInputTransfer+64
e7f34f54 8945f0 mov [ebp-0x10],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64

MODULE_NAME: usbaudio

IMAGE_NAME: usbaudio.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4

STACK_COMMAND: kb

BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64

Followup: MachineOwner

This problem occurs even with some standard USB Audio device.

When there is no bug check the call stack trace as follows :

STACK_TEXT:
eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
eb42f488 e80587bb 80253030 b5c5ff68 80253030
voipbd!IsoSendRequestToUsb+0x27b
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp
@ 2832]
eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
eb42f610 8052d790 80253030 b5c5ff68 00000000
voipbd!MTVoIP_InternalDispatchControl+0x26
[e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
eb42f65c e8040d95 00000000 ffdff120 00000000
nt!IovSpecialIrpCallDriver+0xcd
eb42f680 e8042354 80253030 87433628 00000010
usbaudio!PCM2USB_CallUSBD+0xa5
eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
usbaudio!PCM2USB_WriteReset+0x64
eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
usbaudio!AdapterOpenStream+0x458
eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
usbaudio!AdapterReceivePacket+0x2a
eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
STREAM!SCIssueRequestToDevice+0xad
eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
STREAM!StreamDispatchCreate+0x220
eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c
nt!IovSpecialIrpCallDriver+0xcd
eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
sysaudio!CreatePinNodeInstance+0xbb
eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
sysaudio!CreateConnectNodeInstance+0x11e
eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
sysaudio!CreateStartNodeInstance+0x9b
eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
sysaudio!PinDispatchCreateKP+0x8f
eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
sysaudio!CallKernelProcessWorker+0xe
eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000
nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The voipbd is our driver .

Let me know if you need any more information.

thanks in advance
sri.

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, March 05, 2003 4:15 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

What does the call stack look like when you bugcheck? Also, which sp
number is installed on win2k?

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still
from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the
Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows
anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as
USB
audio device. Everything is normal and working good. When I get a
request
from USB audio driver ( Microsoft ) , if it need to be send down then I
will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system
crashes
with the above error. Instead of calling next level driver with a new
IRP ,
somehow it ends with the IRP that came originally although I never send
it
when this error happens. If the allocation of IRP fails , we will return
the
error to the top layer and that does not happen. The error in debugger
is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came
from
USB audio driver to next layer. How can I ensure it does have enough
stack
locations.

Even though I am checking for stack size before sending the request down
it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows
XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I looked at the code and it just sends IRPs to the stored PDO in its
extension. I am not an expert in kernel streaming, but it looks like
the PDO is set when the miniport is opened. Perhaps ks is opening the
port to a different PDO in the surprise remove case (doubt it though).

One thing is to get a debug usbaudio on the machine (debug version of
windows 2000 findstrshould be available in msdn), then
ed usbaudio!USBAudioDebugLevel

looks like 2 might be your best bet for . is an incremental
value, not a bitfield.

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Friday, March 07, 2003 9:39 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

Hi doron

the information what I gave is insufficient to find any clue of what is
wrong ?

Thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 4:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

Hi doron

Thank you very much for the reply.

It is windows 2000 , sp 1.

call stack looks as follows when it bugchecked:

PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Ejection Relations
PDO Dispatch PnP Child 2 - The Minor Function is 7
PDO Dispatch PnP - Querying the Relations - Removal Relations

FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS

FDO In RemovalRelations
FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS

FDO In EjectionRelations

Fatal System Error: 0x00000035
(0xBDED9F68,0x00000000,0x00000000,0x00000000)

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 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols



Loading unloaded module list

Loading User Symbols

**********************************************************




Bugcheck Analysis







Use !analyze -v to get detailed debugging information.

BugCheck 35, {bded9f68, 0, 0, 0}

WARNING: Unable to verify checksum for VoIPAppsc.exe
ERROR: Module load completed but symbols could not be loaded for
VoIPAppsc.exe
Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
80453d52 cc int 3
kd> !analyze -v





Bugcheck Analysis



*****************************************************************



NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in
the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver “thinks” it has filled in the
parameters for the lower level driver (something it MUST do before it
calls
it), but since there is no stack location for the latter driver, the
former
has written off of the end of the packet. This means that some other
memory
has probably been trashed at this point.
Arguments:
Arg1: bded9f68, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x35

LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52

STACK_TEXT:
e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
nt!RtlpBreakWithStatusInstruction
e7fc2170 8042c1c1 00000003 82cff5b0 00000000
nt!KiBugCheckDebugBreak+0x31
e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
e7fc2554 e7f34f54 00000103 00000001 826581d0
nt!IovSpecialIrpCallDriver+0x9f
e7fc256c e7f353d9 80ea7b08 00000003 826581d0
usbaudio!StartIsocInputTransfer+0x64
e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
usbaudio!CaptureStateChange+0xb9
e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
usbaudio!AudioReceiveCtrlPacket+0x3e
e7fc25dc e80bca18 84f95900 82658008 80ea7b08
STREAM!SCIssueRequestToDevice+0xad
e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08
STREAM!SCStreamDeviceState+0x8c
e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
STREAM!StreamDispatchIoControl+0x228
e7fc2780 8052d790 84f95890 bf81ff48 84f95890
KS!DispatchDeviceIoControl+0x2a
e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574
nt!IovSpecialIrpCallDriver+0xcd
e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2840 eb255bb5 82b4ac48 00000000 00000002
sysaudio!PinConnectionProperty+0x40
e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
e7fc288c eb255f47 00000002 00000003 00000002
sysaudio!SetStateTopDown+0x2a
e7fc28b0 eb255af4 e14fdd30 00000003 00000006
sysaudio!SetPinInstanceState+0x43
e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48
sysaudio!PinStateHandler+0x55
e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
sysaudio!PinDispatchIoControl+0x145
e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850
KS!DispatchDeviceIoControl+0x2a
e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8
nt!IovSpecialIrpCallDriver+0xcd
e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
KS!KsSynchronousIoControlDevice+0xbb
e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
e7fc2c20 80498d61 865726ce 00000000 bf819f48
nt!IovSpecialIrpCallDriver+0xcd
e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
nt!IopSynchronousServiceTail+0x60
e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
e7fc2d34 80462cf1 000000d0 000001e4 00000000
nt!NtDeviceIoControlFile+0x28
e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
00c0fd38 77e886a3 000000d0 000001e4 00000000
ntdll!NtDeviceIoControlFile+0xb
00c0fd9c 77563e73 000000d0 001d8144 0013f6c8
KERNEL32!DeviceIoControl+0x93
00c0fde8 77561524 0013f6c8 00000000 00000000
wdmaud_77560000!wdmaudIoControl+0x93
00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
wdmaud_77560000!wdmaudSetDeviceState+0x6d
00c0fe28 77561b28 0013f6c8 00000000 002f8f10
wdmaud_77560000!waveWrite+0xa8
00c0fe44 77577dc6 00000000 00000038 0013f6c8
wdmaud_77560000!widMessage+0x10e
00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970

FOLLOWUP_IP:
usbaudio!StartIsocInputTransfer+64
e7f34f54 8945f0 mov [ebp-0x10],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64

MODULE_NAME: usbaudio

IMAGE_NAME: usbaudio.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4

STACK_COMMAND: kb

BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64

Followup: MachineOwner
---------

This problem occurs even with some standard USB Audio device.

When there is no bug check the call stack trace as follows :

STACK_TEXT:
eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
eb42f488 e80587bb 80253030 b5c5ff68 80253030
voipbd!IsoSendRequestToUsb+0x27b
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp
@ 2832]
eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
[e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
eb42f610 8052d790 80253030 b5c5ff68 00000000
voipbd!MTVoIP_InternalDispatchControl+0x26
[e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
eb42f65c e8040d95 00000000 ffdff120 00000000
nt!IovSpecialIrpCallDriver+0xcd
eb42f680 e8042354 80253030 87433628 00000010
usbaudio!PCM2USB_CallUSBD+0xa5
eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
usbaudio!PCM2USB_WriteReset+0x64
eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
usbaudio!AdapterOpenStream+0x458
eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
usbaudio!AdapterReceivePacket+0x2a
eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
STREAM!SCIssueRequestToDevice+0xad
eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
STREAM!StreamDispatchCreate+0x220
eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c
nt!IovSpecialIrpCallDriver+0xcd
eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
sysaudio!CreatePinNodeInstance+0xbb
eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
sysaudio!CreateConnectNodeInstance+0x11e
eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
sysaudio!CreateStartNodeInstance+0x9b
eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
sysaudio!PinDispatchCreateKP+0x8f
eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
sysaudio!CallKernelProcessWorker+0xe
eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000
nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The voipbd is our driver .

Let me know if you need any more information.

thanks in advance
sri.

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, March 05, 2003 4:15 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

What does the call stack look like when you bugcheck? Also, which sp
number is installed on win2k?

d

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Can this happen ?

Hi all,

When a device is suddenly removed , if the requests are coming still
from
the top layer Where would the requests go down the layer ?

I am having a case like this :

Usb audio
|
Multifunc --child device object

When the audio application is sending the data down , the multi function
driver creates a new request with the data from USB audio request and
forwards down.

when the application is running, if the device is suddenly removed , the
Usb
audio is request is going to another driver layer directly by passing
Multifunction driver layer. In failed condition , it never shows
anything
related to multifunction driver in stack trace.

In the normal stack trace it always shows that it is going through
multifunction driver.

Anybody has any idea what makes IRP go directly to next layer with out
passing through our driver ?

thanks in advance
sri.

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, March 05, 2003 9:46 AM
To: NT Developers Interest List
Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?

Hi all

Our driver kind of multifunction driver, the child device is treated as
USB
audio device. Everything is normal and working good. When I get a
request
from USB audio driver ( Microsoft ) , if it need to be send down then I
will
prepare a new request and send it down .

The problem occurs when the device is unplugged suddenly, the system
crashes
with the above error. Instead of calling next level driver with a new
IRP ,
somehow it ends with the IRP that came originally although I never send
it
when this error happens. If the allocation of IRP fails , we will return
the
error to the top layer and that does not happen. The error in debugger
is as
follows:

Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )

I am pretty much sure that I am not just forwarding the request came
from
USB audio driver to next layer. How can I ensure it does have enough
stack
locations.

Even though I am checking for stack size before sending the request down
it
is not helping .

This problem occurs only on Windows 2000 and does not occur on Windows
XP.

any ideas.

thanks in advance,
sri.


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I remember seeing a problem like this on pre-SP1 XP dual-proc machine under heavy testing.
It was about year ago so I don’t remember all the details, however at the time we blamed it on
sysaudio.sys (if I am not mistaken.) The problem used to show up under stress tests with Driver
Verifier on.

I believe that the issue got fixed by XP SP1 and/or DX9.
You might want to try SP3 for Win2K and/or DX9 and see if it helps.

Regards,
– Max.

— Doron Holan wrote:
> I looked at the code and it just sends IRPs to the stored PDO in its
> extension. I am not an expert in kernel streaming, but it looks like
> the PDO is set when the miniport is opened. Perhaps ks is opening the
> port to a different PDO in the surprise remove case (doubt it though).
>
> One thing is to get a debug usbaudio on the machine (debug version of
> windows 2000 findstrshould be available in msdn), then
> ed usbaudio!USBAudioDebugLevel
>
> looks like 2 might be your best bet for . is an incremental
> value, not a bitfield.
>
> d
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Friday, March 07, 2003 9:39 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
> Hi doron
>
> the information what I gave is insufficient to find any clue of what is
> wrong ?
>
>
> Thanks in advance
> sri.
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 4:27 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
>
> Hi doron
>
> Thank you very much for the reply.
>
> It is windows 2000 , sp 1.
>
> call stack looks as follows when it bugchecked:
>
> PDO Dispatch PnP Child 2 - The Minor Function is 7
> PDO Dispatch PnP - Querying the Relations - Ejection Relations
> PDO Dispatch PnP Child 2 - The Minor Function is 7
> PDO Dispatch PnP - Querying the Relations - Removal Relations
>
> FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
>
> FDO In RemovalRelations
> FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
>
> FDO In EjectionRelations
>
>
> Fatal System Error: 0x00000035
> (0xBDED9F68,0x00000000,0x00000000,0x00000000)
>
> 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 2000 2195 x86 compatible target, ptr64 FALSE
> Loading Kernel Symbols
> …
> …
> …
> Loading unloaded module list
> …
> Loading User Symbols
> …
>
*********************************************************************
> *
>

> *
> *
> * Bugcheck Analysis
> *
> *
>
>
>

>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 35, {bded9f68, 0, 0, 0}
>
>
WARNING: Unable to verify checksum for VoIPAppsc.exe
> ERROR: Module load completed but symbols could not be loaded for
> VoIPAppsc.exe
> Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 80453d52 cc int 3
> kd> !analyze -v
>

> *
>

> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ********************************************************************
>

> ***
>
> NO_MORE_IRP_STACK_LOCATIONS (35)
> A higher level driver has attempted to call a lower level driver through
> the IoCallDriver() interface, but there are no more stack locations in
> the
> packet, hence, the lower level driver would not be able to access its
> parameters, as there are no parameters for it. This is a disasterous
> situation, since the higher level driver “thinks” it has filled in the
> parameters for the lower level driver (something it MUST do before it
> calls
> it), but since there is no stack location for the latter driver, the
> former
> has written off of the end of the packet. This means that some other
> memory
> has probably been trashed at this point.
> Arguments:
> Arg1: bded9f68, Address of the IRP
> Arg2: 00000000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x35
>
> LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52
>
> STACK_TEXT:
> e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
> nt!RtlpBreakWithStatusInstruction
> e7fc2170 8042c1c1 00000003 82cff5b0 00000000
> nt!KiBugCheckDebugBreak+0x31
> e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
> e7fc2554 e7f34f54 00000103 00000001 826581d0
> nt!IovSpecialIrpCallDriver+0x9f
> e7fc256c e7f353d9 80ea7b08 00000003 826581d0
> usbaudio!StartIsocInputTransfer+0x64
> e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
> usbaudio!CaptureStateChange+0xb9
> e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
> e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
> usbaudio!AudioReceiveCtrlPacket+0x3e
> e7fc25dc e80bca18 84f95900 82658008 80ea7b08
> STREAM!SCIssueRequestToDevice+0xad
> e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
> e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08
> STREAM!SCStreamDeviceState+0x8c
> e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
> e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
> e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
> STREAM!StreamDispatchIoControl+0x228
> e7fc2780 8052d790 84f95890 bf81ff48 84f95890
> KS!DispatchDeviceIoControl+0x2a
> e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
> KS!KsSynchronousIoControlDevice+0xbb
> e7fc2840 eb255bb5 82b4ac48 00000000 00000002
> sysaudio!PinConnectionProperty+0x40
> e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
> e7fc288c eb255f47 00000002 00000003 00000002
> sysaudio!SetStateTopDown+0x2a
> e7fc28b0 eb255af4 e14fdd30 00000003 00000006
> sysaudio!SetPinInstanceState+0x43
> e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48
> sysaudio!PinStateHandler+0x55
> e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
> e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
> e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
> sysaudio!PinDispatchIoControl+0x145
> e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850
> KS!DispatchDeviceIoControl+0x2a
> e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
> KS!KsSynchronousIoControlDevice+0xbb
> e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
> e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
> e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
> e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
> e7fc2c20 80498d61 865726ce 00000000 bf819f48
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
> nt!IopSynchronousServiceTail+0x60
> e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
> e7fc2d34 80462cf1 000000d0 000001e4 00000000
> nt!NtDeviceIoControlFile+0x28
> e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
> 00c0fd38 77e886a3 000000d0 000001e4 00000000
> ntdll!NtDeviceIoControlFile+0xb
> 00c0fd9c 77563e73 000000d0 001d8144 0013f6c8
> KERNEL32!DeviceIoControl+0x93
> 00c0fde8 77561524 0013f6c8 00000000 00000000
> wdmaud_77560000!wdmaudIoControl+0x93
> 00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
> wdmaud_77560000!wdmaudSetDeviceState+0x6d
> 00c0fe28 77561b28 0013f6c8 00000000 002f8f10
> wdmaud_77560000!waveWrite+0xa8
> 00c0fe44 77577dc6 00000000 00000038 0013f6c8
> wdmaud_77560000!widMessage+0x10e
> 00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
> 00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970
>
>
> FOLLOWUP_IP:
> usbaudio!StartIsocInputTransfer+64
> e7f34f54 8945f0 mov [ebp-0x10],eax
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64
>
> MODULE_NAME: usbaudio
>
> IMAGE_NAME: usbaudio.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64
>
> Followup: MachineOwner
> ---------
>
> This problem occurs even with some standard USB Audio device.
>
>
> When there is no bug check the call stack trace as follows :
>
> STACK_TEXT:
> eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
> eb42f488 e80587bb 80253030 b5c5ff68 80253030
> voipbd!IsoSendRequestToUsb+0x27b
> [e:\voip\drivers\voipbusdriver\ctrlurb.cpp
> @ 2832]
> eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
> voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
> [e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
> eb42f610 8052d790 80253030 b5c5ff68 00000000
> voipbd!MTVoIP_InternalDispatchControl+0x26
> [e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
> eb42f65c e8040d95 00000000 ffdff120 00000000
> nt!IovSpecialIrpCallDriver+0xcd
> eb42f680 e8042354 80253030 87433628 00000010
> usbaudio!PCM2USB_CallUSBD+0xa5
> eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
> usbaudio!PCM2USB_WriteReset+0x64
> eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
> usbaudio!AdapterOpenStream+0x458
> eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
> usbaudio!AdapterReceivePacket+0x2a
> eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
> STREAM!SCIssueRequestToDevice+0xad
> eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
> eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
> STREAM!StreamDispatchCreate+0x220
> eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
> eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c
> nt!IovSpecialIrpCallDriver+0xcd
> eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
> eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
> eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
> eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
> eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
> eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
> eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
> eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
> sysaudio!CreatePinNodeInstance+0xbb
> eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
> sysaudio!CreateConnectNodeInstance+0x11e
> eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
> sysaudio!CreateStartNodeInstance+0x9b
> eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
> sysaudio!PinDispatchCreateKP+0x8f
> eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
> sysaudio!CallKernelProcessWorker+0xe
> eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
> eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
> eb42fddc 804671c2 80418a7c 00000000 00000000
> nt!PspSystemThreadStartup+0x69
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The voipbd is our driver .
>
>
> Let me know if you need any more information.
>
>
> thanks in advance
> sri.
>
>
>
> -----Original Message-----
> From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
> Sent: Wednesday, March 05, 2003 4:15 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
>
> What does the call stack look like when you bugcheck? Also, which sp
> number is installed on win2k?
>
> d
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 11:31 AM
> To: NT Developers Interest List
> Subject: [ntdev] Can this happen ?
>
> Hi all,
>
> When a device is suddenly removed , if the requests are coming still
> from
> the top layer Where would the requests go down the layer ?
>
> I am having a case like this :
>
> Usb audio
> |
> Multifunc --child device object
>
> When the audio application is sending the data down , the multi function
> driver creates a new request with the data from USB audio request and
> forwards down.
>
> when the application is running, if the device is suddenly removed , the
> Usb
> audio is request is going to another driver layer directly by passing
> Multifunction driver layer. In failed condition , it never shows
> anything
> related to multifunction driver in stack trace.
>
> In the normal stack trace it always shows that it is going through
> multifunction driver.
>
> Anybody has any idea what makes IRP go directly to next layer with out
> passing through our driver ?
>
> thanks in advance
> sri.
>
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 9:46 AM
> To: NT Developers Interest List
> Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?
>
>
> Hi all
>
> Our driver kind of multifunction driver, the child device is treated as
> USB
> audio device. Everything is normal and working good. When I get a
> request
> from USB audio driver ( Microsoft ) , if it need to be send down then I
> will
> prepare a new request and send it down .
>
> The problem occurs when the device is unplugged suddenly, the system
> crashes
> with the above error. Instead of calling next level driver with a new
> IRP ,
> somehow it ends with the IRP that came originally although I never send
> it
> when this error happens. If the allocation of IRP fails , we will return
> the
> error to the top layer and that does not happen. The error in debugger
> is as
> follows:
>
> Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )
>
> I am pretty much sure that I am not just forwarding the request came
> from
> USB audio driver to next layer. How can I ensure it does have enough
> stack
> locations.
>
> Even though I am checking for stack size before sending the request down
> it
> is not helping .
>
> This problem occurs only on Windows 2000 and does not occur on Windows
> XP.
>
> any ideas.
>
> thanks in advance,
> sri.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Hi Max

Thanks for the reply.

This problem does not happen on windows XP, it happens on Win2K , sp1 . I
have not tested it on Win2k ,Sp3 .

Our problem is something like this, after the device is unplugged , if I try
to create new IRP and send it down it blows off . Now what I have done is I
stopped creating IRP’s during this time and started reusing IRP’s which were
created before. With this crash does not happen now . I don’t know why it
has to fail that way .

Is it a bug in Usbaudio.sys ?

Anyway I will check with debug version of Usb audio and see what happens as
suggested by Doron.

Thanks
srinivasa

-----Original Message-----
From: Max Paklin [mailto:xxxxx@yahoo.com]
Sent: Friday, March 07, 2003 5:26 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Can this happen ?

I remember seeing a problem like this on pre-SP1 XP dual-proc machine under
heavy testing.
It was about year ago so I don’t remember all the details, however at the
time we blamed it on
sysaudio.sys (if I am not mistaken.) The problem used to show up under
stress tests with Driver
Verifier on.

I believe that the issue got fixed by XP SP1 and/or DX9.
You might want to try SP3 for Win2K and/or DX9 and see if it helps.

Regards,
– Max.

— Doron Holan wrote:
> I looked at the code and it just sends IRPs to the stored PDO in its
> extension. I am not an expert in kernel streaming, but it looks like
> the PDO is set when the miniport is opened. Perhaps ks is opening the
> port to a different PDO in the surprise remove case (doubt it though).
>
> One thing is to get a debug usbaudio on the machine (debug version of
> windows 2000 findstrshould be available in msdn), then
> ed usbaudio!USBAudioDebugLevel
>
> looks like 2 might be your best bet for . is an incremental
> value, not a bitfield.
>
> d
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Friday, March 07, 2003 9:39 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
> Hi doron
>
> the information what I gave is insufficient to find any clue of what is
> wrong ?
>
>
> Thanks in advance
> sri.
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 4:27 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
>
> Hi doron
>
> Thank you very much for the reply.
>
> It is windows 2000 , sp 1.
>
> call stack looks as follows when it bugchecked:
>
> PDO Dispatch PnP Child 2 - The Minor Function is 7
> PDO Dispatch PnP - Querying the Relations - Ejection Relations
> PDO Dispatch PnP Child 2 - The Minor Function is 7
> PDO Dispatch PnP - Querying the Relations - Removal Relations
>
> FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
>
> FDO In RemovalRelations
> FDO Dispatch PnP - The Minor Function is IRP_MN_QUERY_DEVICE_RELATIONS
>
> FDO In EjectionRelations
>
>
> Fatal System Error: 0x00000035
> (0xBDED9F68,0x00000000,0x00000000,0x00000000)
>
> 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 2000 2195 x86 compatible target, ptr64 FALSE
> Loading Kernel Symbols
> …
> …
> …
> Loading unloaded module list
> …
> Loading User Symbols
> …
>
*********************************************************************
> *
>

> *
> *
> * Bugcheck Analysis
> *
> *
>
>
>

>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 35, {bded9f68, 0, 0, 0}
>
>
WARNING: Unable to verify checksum for VoIPAppsc.exe
> ERROR: Module load completed but symbols could not be loaded for
> VoIPAppsc.exe
> Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 80453d52 cc int 3
> kd> !analyze -v
>

> *
>

> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ********************************************************************
>

> ***
>
> NO_MORE_IRP_STACK_LOCATIONS (35)
> A higher level driver has attempted to call a lower level driver through
> the IoCallDriver() interface, but there are no more stack locations in
> the
> packet, hence, the lower level driver would not be able to access its
> parameters, as there are no parameters for it. This is a disasterous
> situation, since the higher level driver “thinks” it has filled in the
> parameters for the lower level driver (something it MUST do before it
> calls
> it), but since there is no stack location for the latter driver, the
> former
> has written off of the end of the packet. This means that some other
> memory
> has probably been trashed at this point.
> Arguments:
> Arg1: bded9f68, Address of the IRP
> Arg2: 00000000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x35
>
> LAST_CONTROL_TRANSFER: from 8042bdfd to 80453d52
>
> STACK_TEXT:
> e7fc2140 8042bdfd 00000003 e7fc2188 bded9f68
> nt!RtlpBreakWithStatusInstruction
> e7fc2170 8042c1c1 00000003 82cff5b0 00000000
> nt!KiBugCheckDebugBreak+0x31
> e7fc24fc 8052d762 00000035 bded9f68 00000000 nt!KeBugCheckEx+0x390
> e7fc2554 e7f34f54 00000103 00000001 826581d0
> nt!IovSpecialIrpCallDriver+0x9f
> e7fc256c e7f353d9 80ea7b08 00000003 826581d0
> usbaudio!StartIsocInputTransfer+0x64
> e7fc2584 e7f29b5e 80ea7b08 00000002 826581d0
> usbaudio!CaptureStateChange+0xb9
> e7fc2598 e7f2a06e 80ea7b08 00000001 8041ee5b usbaudio!SetAudioState+0x3e
> e7fc25c0 e80b9cfd 80ea7b08 80ea7b80 80ea7b08
> usbaudio!AudioReceiveCtrlPacket+0x3e
> e7fc25dc e80bca18 84f95900 82658008 80ea7b08
> STREAM!SCIssueRequestToDevice+0xad
> e7fc260c e80bf8e4 00000003 00000003 00000000 STREAM!SCSubmitRequest+0xae
> e7fc2658 eaf41312 bf81ff48 84f2bd10 84f2bd08
> STREAM!SCStreamDeviceState+0x8c
> e7fc26f4 eaf40e46 bf81ff48 00000003 e80c1110 KS!KspPropertyHandler+0x5ba
> e7fc2714 e80bf814 bf81ff48 00000003 e80c1110 KS!KsPropertyHandler+0x17
> e7fc2774 eaf40a28 84f95890 bf81ff48 8052d790
> STREAM!StreamDispatchIoControl+0x228
> e7fc2780 8052d790 84f95890 bf81ff48 84f95890
> KS!DispatchDeviceIoControl+0x2a
> e7fc27cc eaf40ab0 e7fc2838 eb25a2d0 e16c1574
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc27f8 eb255b5b 82b4ac48 00000000 002f0003
> KS!KsSynchronousIoControlDevice+0xbb
> e7fc2840 eb255bb5 82b4ac48 00000000 00000002
> sysaudio!PinConnectionProperty+0x40
> e7fc2868 eb255cd2 00000003 00000003 00000002 sysaudio!SetState+0x54
> e7fc288c eb255f47 00000002 00000003 00000002
> sysaudio!SetStateTopDown+0x2a
> e7fc28b0 eb255af4 e14fdd30 00000003 00000006
> sysaudio!SetPinInstanceState+0x43
> e7fc28c8 eaf41312 bf7cdf48 8700ef50 8700ef48
> sysaudio!PinStateHandler+0x55
> e7fc2964 eaf40e46 bf7cdf48 00000003 eb250f10 KS!KspPropertyHandler+0x5ba
> e7fc2984 eb255df5 bf7cdf48 00000003 eb250f10 KS!KsPropertyHandler+0x17
> e7fc29d8 eaf40a28 82bde850 bf7cdf48 8052d790
> sysaudio!PinDispatchIoControl+0x145
> e7fc29e4 8052d790 82bde850 bf7cdf48 82bde850
> KS!DispatchDeviceIoControl+0x2a
> e7fc2a30 eaf40ab0 e7fc2a9c e873d980 865725e8
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc2a5c e8731e0d 829e45c8 00000000 002f0003
> KS!KsSynchronousIoControlDevice+0xbb
> e7fc2aa4 e8731db5 829e45c8 e873d970 00000000 wdmaud!PinProperty+0x49
> e7fc2ac4 e8739f7c 8743fba8 00000003 ff5be000 wdmaud!StateWavePin+0x29
> e7fc2ad8 e873a700 ff5be7cc 00000003 8146eb00 wdmaud!StateWaveInPin+0x52
> e7fc2bd4 8052d790 8146eb00 bf819f48 80064b6c wdmaud!SoundDispatch+0x902
> e7fc2c20 80498d61 865726ce 00000000 bf819f48
> nt!IovSpecialIrpCallDriver+0xcd
> e7fc2c34 8049c0e8 8146eb00 bf819f48 84bb2388
> nt!IopSynchronousServiceTail+0x60
> e7fc2d00 804a2317 000000d0 000001e4 00000000 nt!IopXxxControlFile+0x5e4
> e7fc2d34 80462cf1 000000d0 000001e4 00000000
> nt!NtDeviceIoControlFile+0x28
> e7fc2d34 77f8316e 000000d0 000001e4 00000000 nt!KiSystemService+0xc4
> 00c0fd38 77e886a3 000000d0 000001e4 00000000
> ntdll!NtDeviceIoControlFile+0xb
> 00c0fd9c 77563e73 000000d0 001d8144 0013f6c8
> KERNEL32!DeviceIoControl+0x93
> 00c0fde8 77561524 0013f6c8 00000000 00000000
> wdmaud_77560000!wdmaudIoControl+0x93
> 00c0fe0c 77562097 0013f6c8 001d8144 002f8f10
> wdmaud_77560000!wdmaudSetDeviceState+0x6d
> 00c0fe28 77561b28 0013f6c8 00000000 002f8f10
> wdmaud_77560000!waveWrite+0xa8
> 00c0fe44 77577dc6 00000000 00000038 0013f6c8
> wdmaud_77560000!widMessage+0x10e
> 00c0fe6c 7758a272 0013f5bc 00000038 002f8f10 WINMM!waveMessage+0x60
> 00c0fe88 00401970 0013f5bc 002f8f10 00000020 WINMM!waveInAddBuffer+0x53
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 00000000 00000000 00000000 00000000 00000000 VoIPAppsc+0x1970
>
>
> FOLLOWUP_IP:
> usbaudio!StartIsocInputTransfer+64
> e7f34f54 8945f0 mov [ebp-0x10],eax
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: usbaudio!StartIsocInputTransfer+64
>
> MODULE_NAME: usbaudio
>
> IMAGE_NAME: usbaudio.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3803cad4
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0x35_usbaudio!StartIsocInputTransfer+64
>
> Followup: MachineOwner
> ---------
>
> This problem occurs even with some standard USB Audio device.
>
>
> When there is no bug check the call stack trace as follows :
>
> STACK_TEXT:
> eb42f448 e8059d1d 80253030 80064bdc 00000001 nt!DbgBreakPoint
> eb42f488 e80587bb 80253030 b5c5ff68 80253030
> voipbd!IsoSendRequestToUsb+0x27b
> [e:\voip\drivers\voipbusdriver\ctrlurb.cpp
> @ 2832]
> eb42f5fc e8053cf6 80253030 b5c5ff68 802530e8
> voipbd!MTVoIP_PDO_InternalDispatchControl+0xc6e
> [e:\voip\drivers\voipbusdriver\ctrlurb.cpp @ 1034]
> eb42f610 8052d790 80253030 b5c5ff68 00000000
> voipbd!MTVoIP_InternalDispatchControl+0x26
> [e:\voip\drivers\voipbusdriver\drventry.cpp @ 469]
> eb42f65c e8040d95 00000000 ffdff120 00000000
> nt!IovSpecialIrpCallDriver+0xcd
> eb42f680 e8042354 80253030 87433628 00000010
> usbaudio!PCM2USB_CallUSBD+0xa5
> eb42f698 e80406f8 87c19f30 869c40e8 83d09a48
> usbaudio!PCM2USB_WriteReset+0x64
> eb42f6c4 e80409fa 83d09a48 869c42e8 eb42f6f0
> usbaudio!AdapterOpenStream+0x458
> eb42f6d4 e824fcfd 83d09a48 83d09ac0 83d09a48
> usbaudio!AdapterReceivePacket+0x2a
> eb42f6f0 e8252a18 869c4000 87c19d68 83d09a48
> STREAM!SCIssueRequestToDevice+0xad
> eb42f720 e825531c 00000101 8319ca88 00000000 STREAM!SCSubmitRequest+0xae
> eb42f770 eaf403d4 869c4001 b5c23f48 869c4030
> STREAM!StreamDispatchCreate+0x220
> eb42f798 8052d790 869c4030 b5c23f48 eb42fb88 KS!DispatchCreate+0xd2
> eb42f7e4 8049c7cf 84f33c88 eb42fb88 eb42fb0c
> nt!IovSpecialIrpCallDriver+0xcd
> eb42f96c 804a0b80 869c4030 00000000 eb42fa50 nt!IopParseDevice+0xa04
> eb42f9a4 8044ed93 84f33c88 00000000 eb42fa50 nt!IopParseFile+0x4b
> eb42fa10 8049a7fb 00000268 eb42fb0c 00000040 nt!ObpLookupObjectName+0xde
> eb42fb20 8049caab 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc5
> eb42fbf4 eaf417c0 e2e61c18 40000000 eb42fc40 nt!IoCreateFile+0x3ec
> eb42fc6c eaf416b4 00000268 eaf416b8 e2e17070 KS!KsiCreateObjectType+0xbe
> eb42fc88 eb276a51 00000268 e2e17070 40000000 KS!KsCreatePin+0x31
> eb42fcb4 eb27694f e165fe68 e164b450 e292d8f0
> sysaudio!CreatePinNodeInstance+0xbb
> eb42fcec eb2761c4 e2915254 eb42fd14 e292d870
> sysaudio!CreateConnectNodeInstance+0x11e
> eb42fd1c eb276512 e16de250 e293ed10 87cfcf68
> sysaudio!CreateStartNodeInstance+0x9b
> eb42fd50 eb2747bc e16de250 87cfcf68 e823e498
> sysaudio!PinDispatchCreateKP+0x8f
> eb42fd60 eaf40b31 e823e46c 83d09268 8046afc0
> sysaudio!CallKernelProcessWorker+0xe
> eb42fd78 80418b41 83d09268 00000000 00000000 KS!WorkerThread+0x24
> eb42fda8 8045336a 83d09268 00000000 00000000 nt!ExpWorkerThread+0xae
> eb42fddc 804671c2 80418a7c 00000000 00000000
> nt!PspSystemThreadStartup+0x69
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The voipbd is our driver .
>
>
> Let me know if you need any more information.
>
>
> thanks in advance
> sri.
>
>
>
> -----Original Message-----
> From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
> Sent: Wednesday, March 05, 2003 4:15 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Can this happen ?
>
>
> What does the call stack look like when you bugcheck? Also, which sp
> number is installed on win2k?
>
> d
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 11:31 AM
> To: NT Developers Interest List
> Subject: [ntdev] Can this happen ?
>
> Hi all,
>
> When a device is suddenly removed , if the requests are coming still
> from
> the top layer Where would the requests go down the layer ?
>
> I am having a case like this :
>
> Usb audio
> |
> Multifunc --child device object
>
> When the audio application is sending the data down , the multi function
> driver creates a new request with the data from USB audio request and
> forwards down.
>
> when the application is running, if the device is suddenly removed , the
> Usb
> audio is request is going to another driver layer directly by passing
> Multifunction driver layer. In failed condition , it never shows
> anything
> related to multifunction driver in stack trace.
>
> In the normal stack trace it always shows that it is going through
> multifunction driver.
>
> Anybody has any idea what makes IRP go directly to next layer with out
> passing through our driver ?
>
> thanks in advance
> sri.
>
>
>
> -----Original Message-----
> From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
> Sent: Wednesday, March 05, 2003 9:46 AM
> To: NT Developers Interest List
> Subject: [ntdev] Help : How to stop NO_MORE_IRP_STACK_LOCATIONS ?
>
>
> Hi all
>
> Our driver kind of multifunction driver, the child device is treated as
> USB
> audio device. Everything is normal and working good. When I get a
> request
> from USB audio driver ( Microsoft ) , if it need to be send down then I
> will
> prepare a new request and send it down .
>
> The problem occurs when the device is unplugged suddenly, the system
> crashes
> with the above error. Instead of calling next level driver with a new
> IRP ,
> somehow it ends with the IRP that came originally although I never send
> it
> when this error happens. If the allocation of IRP fails , we will return
> the
> error to the top layer and that does not happen. The error in debugger
> is as
> follows:
>
> Probably caused by : usbaudio.sys ( usbaudio!StartIsocInputTransfer+64 )
>
> I am pretty much sure that I am not just forwarding the request came
> from
> USB audio driver to next layer. How can I ensure it does have enough
> stack
> locations.
>
> Even though I am checking for stack size before sending the request down
> it
> is not helping .
>
> This problem occurs only on Windows 2000 and does not occur on Windows
> XP.
>
> any ideas.
>
> thanks in advance,
> sri.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microtune.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


You are currently subscribed to ntdev as: xxxxx@microtune.com
To unsubscribe send a blank email to xxxxx@lists.osr.com