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