"Attach" or "Break" not possible...
Jochen Kalmbach
we have an application which is "resistent" against debugging :-<
The problem is that this application "hangs" after a couple of hours.
If it was started under the debugger (tred VS or cdb) it is NOT possible to
"break"!
If it was started without debugger, it is not possible to "attach" to this
process.
What might be the reason for this BIG trouble !?
We are not able to find the source of the hanging...
I even tried using the "Create crash dump" feature, to procude an kernel-
mode crash-dump after the process hanged... but I could not extract any
usefull information in the callstacks of the target process...
What can I do now ?
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Ivan Brugiolo [MSFT]
c:\debuggers>cdb -pv -p <pid>
and inspect that state from there.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns955CBD66BE1FDno...@207.46.248.16...
Jochen Kalmbach
> Try non-invasive debugging:
> c:\debuggers>cdb -pv -p <pid>
> and inspect that state from there.
Thanx for your comment!
But I still have the same problem.
I wrote a logfile of the session:..
<log>
D:\SW>"C:\Programme\Debugging Tools for Windows\cdb.exe" -pv -pn SW.exe
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: *** Invalid ***
*************************************************************************
***
* Symbol loading may be unreliable without a symbol search path.
*
* Use .symfix to have the debugger choose a symbol path.
*
* After setting your symbol path, use .reload to refresh symbol
locations. *
*************************************************************************
***
Executable search path is:
WARNING: Process 240 is not attached as a debuggee
The process can be examined but debug events will not be
received
.......................................
(f0.ec): Wake debugger - code 80000007 (first chance)
</log>
And this is all.... the debugger never responds anymore...
Normally it should display the "prompt">
I also tried with "websymbols and symsrv... same result...
Do you have any ideas !?
Ivan Brugiolo [MSFT]
0:000>
at a certain point ?
If you have that prompt, you can start poking around the state of the
application.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns955E7E02C986CJ...@127.0.0.1...
Jochen Kalmbach
> Do you get a a prompt like
> 0:000>
> at a certain point ?
> If you have that prompt, you can start poking around the state of the
> application.
No, I do not get a prompt... that is my problem...
vipin
the DllMain and probably then the debugger attach would work afterwards.
Thanks
vipin
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns955F4C0F1141AJ...@127.0.0.1...
Pavel Lebedinsky
it is doing.
Rhett Gong [MSFT]
Maybe you could have KD attached and get a dump of the system when the app
goes unresponsive.
Thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.
Jochen Kalmbach
> Seems you are trying to debug a process with anti-debug features.
No, I want to debug MY program!
> Maybe you could have KD attached and get a dump of the system when the
> app goes unresponsive.
I also tried this, but I could not get any usefull info out of this dump.
Rhett Gong [MSFT]
Since it is your your, I suspect that other debugger is already attached.
Could you try to attach it with windbg and let me know what you get please?
Windbg should display some helpful information in this case.
Best regards,
Jochen Kalmbach
> And you said it can't be attached.
> Since it is your your, I suspect that other debugger is already
> attached. Could you try to attach it with windbg and let me know what
> you get please?
> Windbg should display some helpful information in this case.
I tried top attach with cdb, which should be the same as windbg...
If I do the following:
cdb.exe -pv -pn APP.exe -cf cmds.txt
I get:
<log>
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: *** Invalid ***
************************************************************************
****
* Symbol loading may be unreliable without a symbol search path.
*
* Use .symfix to have the debugger choose a symbol path.
*
* After setting your symbol path, use .reload to refresh symbol
locations. *
************************************************************************
****
Executable search path is:
WARNING: Process 240 is not attached as a debuggee
The process can be examined but debug events will not be
received
.......................................
(f0.ec): Wake debugger - code 80000007 (first chance)
</log>
Normally it should display the registers and the breakpoint; and then
the prompt....
But it just stays there... no prompt...
I also tried the "normal"
cdb.exe -pn APP.exe -bonc -cf cmds.txt
Same result...
I also tried to let the debugee run under the debugger:
cdb.exe -g -G -2 APP.EXE
Same result: I am not able to press Ctrl-C/Break... no reaction.... no
prompt...
Now I put an other thread into my app, which should call "DebugBreak" if
it get signaled... maybe it works, we will see in a couple of hours (if
I test it, it works...; but maybe on the tagret machine we habe the same
result as with attaching...)
Rhett Gong [MSFT]
>it get signaled... maybe it works, we will see in a couple of hours (if
>I test it, it works...; but maybe on the tagret machine we habe the same
>result as with attaching...)
Since this is your code, could you add " _asm {int 3} " in the entry of the
program to see if you could attach the debugger to.
Not sure what your code is, do you have any thread in kernel mode that
prevent the debugger's attach? You could use local kd to check this.
Thanks,
Jochen Kalmbach
>>Now I put an other thread into my app, which should call "DebugBreak"
>>if it get signaled... maybe it works, we will see in a couple of hours
>>(if I test it, it works...; but maybe on the tagret machine we habe
>>the same result as with attaching...)
> What's your result?
I have not yet an result.... I have to wait until it happens...
> Since this is your code, could you add " _asm {int 3} " in the entry
> of the program to see if you could attach the debugger to.
It is no problem to let the app run under the debugger... it is also not
problem to attach the debugger to the app, EXCEPT if my app hangs... then
I cannot break into the app (neither if I started it under the debugger,
nor with attach).
> Not sure what your code is, do you have any thread in kernel mode that
> prevent the debugger's attach? You could use local kd to check this.
I am not aware of shuch threads... I am using DDEML (for DDE-
Communication), maybe this prevents the debugger from attaching...
My app hangs if the DDE-Server also hangs...
Jochen Kalmbach
> Rhett Gong [MSFT] wrote:
>
>>>Now I put an other thread into my app, which should call "DebugBreak"
>>>if it get signaled... maybe it works, we will see in a couple of
>>>hours (if I test it, it works...; but maybe on the tagret machine we
>>>habe the same result as with attaching...)
>> What's your result?
>
> I have not yet an result.... I have to wait until it happens...
Ok, now I have the result:
Same behaviour...
My thread gets signaled and the I call "MiniDumpWriteDump"... it creates an
dump-file but then it also hangs (the dump-file is 0 bytes...)
Rhett Gong [MSFT]
>problem to attach the debugger to the app, EXCEPT if my app hangs... then
>I cannot break into the app
>My thread gets signaled and the I call "MiniDumpWriteDump"... it creates
an
>dump-file but then it also hangs (the dump-file is 0 bytes...)
Do you mean that the "Create crash dump" feature also create the 0bytes
dump file?
Have you tried using local kd? With local kd, you could get full access to
the user and kernel address space.
Best regards,
Rhett Gong [MSFT]
feel free to let me know if there is anything I could assist.
thanks,
Jochen Kalmbach
> How about using local kd? Have you got anything useful from it?
> Please feel free to let me know if there is anything I could assist.
I know created a complete-memroy-crash-dump (with Ctrl-SrcolLock) while
the app was hanging (and the MiniDumpWriteDump also hangs):
Here is the callstack of the MiniDumpWriteDump-Thread, maybe you will
see more...
How can I find out on WHAT event this thread is waiting?
THREAD 81b76720 Cid 0994.0a30 Teb: 7ffaf000 Win32Thread:
00000000 WAIT: (Executive) KernelMode Non-Alertable
f5425a3c NotificationEvent
Not impersonating
DeviceMap e17ec1f8
Owning Process 81cb2690
Wait Start TickCount 4040160 Elapsed Ticks: 166522
Context Switch Count 281
UserTime 00:00:00.0000
KernelTime 00:00:00.0000
Start Address kernel32!BaseThreadStartThunk (0x77e7d342)
Win32 Start Address Myapp!AliveWatchTask (0x00487850)
Stack Init f5426000 Current f5425978 Base f5426000 Limit
f5423000 Call 0
Priority 24 BasePriority 24 PriorityDecrement 0 DecrementCount 0
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for -
ChildEBP RetAddr Args to Child
f5425990 804fd78e 81b76790 81b76720 f5425a3c nt!KiSwapContext+
0x2f (FPO: [EBP 0xf54259c8] [0,0,4])
f54259a0 804f64e8 00000002 81dea8e0 00000000 nt!KiSwapThread+
0x6a (FPO: [EBP 0xf54259c8] [0,0,4])
f54259c8 805b19b1 00000000 00000000 00000000 nt!
KeWaitForSingleObject+0x1c0 (FPO: [Non-Fpo])
f5425d34 805b1a68 81dea8e0 05af276c 00000001 nt!
PsGetContextThread+0x169 (FPO: [Non-Fpo])
f5425d54 805306a4 81dea8e0 05af276c 00000000 nt!
NtGetContextThread+0x4c (FPO: [Non-Fpo])
f5425d54 7ffe0304 81dea8e0 05af276c 00000000 nt!KiSystemService+
0xc9 (FPO: [0,0] TrapFrame @ f5425d64)
0314e5d8 77f5b994 77e938d0 000001f4 05af276c SharedUserData!
SystemCallStub+0x4 (FPO: [0,0,0])
0314e5dc 77e938d0 000001f4 05af276c 6d53503f ntdll!
NtGetContextThread+0xc (FPO: [2,0,0])
0314e5e8 6d53503f 000001f4 05af276c 00000994 kernel32!
GetThreadContext+0xe (FPO: [2,0,0])
WARNING: Stack unwind information not available. Following frames may be
wrong.
0314e614 6d535f60 001578b0 ffffffff 00000d18 dbghelp!
MiniDumpReadDumpStream+0xfe1
0314f2a0 6d5354a4 ffffffff 00000994 00000000 dbghelp!
MiniDumpReadDumpStream+0x1f02
0314f2cc 6d533fc2 ffffffff 00000994 00000000 dbghelp!
MiniDumpReadDumpStream+0x1446
0314f3a0 00340e63 ffffffff 00000994 000002e4 dbghelp!
MiniDumpWriteDump+0x9a
0314fbac 77e98854 0314fbd4 77e94858 0314fbdc kernel32!
UnhandledExceptionFilter+0x10a (FPO: [Non-Fpo])
0314ffec 00000000 00487850 00000000 00000000 kernel32!
BaseThreadStart+0x4d (FPO: [Non-Fpo])
Yan-Hong Huang[MSFT]
Thanks very much for your update. This problem is complicated. Currently we
are looking for somebody in dbg team to look into the issue. This may need
some time, however, please rest assured taht we will return here with some
more information as soon as possible.
By the way, if you register a no spam email address according to my
signature. We can send notify email to you when we reply more information.
If there is any question, please feel free to post here. Have a good day.
Best regards,
Yanhong Huang
Microsoft Community Support
Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn
Seshadri Krishnaswamy [MSFT]
Can you give more description on what your application does and the problem
that you are seeing? Does the problem reproduce on all the machines? What
is the OS that you are having issue with?
Also, when you try CTRL+Break in windbg, do you a message that reads
"Break-in sent, waiting 30 seconds..." in the command output window? If so
what other messages do you see following the break-in message?
Thanks!
----
-Sesha
Windows Developer Support
Yan-Hong Huang[MSFT]
Sesha from Winbase team has replied you. Could you pleaes reply his post to
provide more information for troubleshooting?
Thanks very much.
Best regards,
Yanhong Huang
Microsoft Community Support
Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn
This posting is provided "AS IS" with no warranties, and confers no rights.
Yan-Hong Huang[MSFT]
How is everything going? If the problem is not resolved, please reply
Sesha's post in the newsgroup and he will follow up it with you.
Jochen Kalmbach
> Can you give more description on what your application does and the
> problem that you are seeing? Does the problem reproduce on all the
> machines? What is the OS that you are having issue with?
It seems that it has something to do with an serial port (COMx).
We open/close it very often. If we do not use this serial port, the program
does not hang...
So for now it seems to be "solved".
Thanx for all your help!
Yan-Hong Huang[MSFT]
Thanks very much for your update. We are glad to learn that the problem is
resolved now. If you have any more concerns on the programming, please feel
free to post in the newsgroup and we will follow up.
Thanks again for participating the community. :) Have a good day.
Best regards,
Yanhong Huang
Microsoft Community Support
Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn
This posting is provided "AS IS" with no warranties, and confers no rights.