Mail Archives: cygwin/2004/12/30/18:57:20
On Thu, Dec 30, 2004 at 03:39:38PM -0800, Hans Horn wrote:
>Christopher Faylor wrote:
>> On Wed, Dec 29, 2004 at 04:16:00PM -0800, Hans Horn wrote:
>>> I'm trying to debug a running process by attaching the debugger to
>>> it.
>>>
>>> From inside the debugger, when I issue a 'where' command, I end up in
>>>
>>> Switching to thread 3344.0x564]
>>> #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from
>>> /cygdrive/c/WINDOWS/system32/ntdll.dll
>>> #1 0x7c9507a8 in ntdll!KiIntSystemCall () from
>>> /cygdrive/c/WINDOWS/system32/ntdll.dll
>>> #2 0x00000005 in ?? ()
>>> #3 0x00000004 in ?? ()
>>> #4 0x00000001 in ?? ()
>>> #5 0x0238ffd0 in ?? ()
>>>
>>> When I try to step out of this. insight freezes.
>>>
>>> Anybody else seen this?
>>
>> Seen what? Seen that windows creates a new thread when you are
>> attaching to a process. Yes.
>
>No - that the dbugger freezes when i try to do a step or a next!
I wouldn't suggest trying to step or next in a thread that is
entirely created by windows.
>> Look at thread 1. It probably will be more informative.
>
>Alright, there are four threads.
>the debugger wakes up in thread 4 (ntdll!DbgUiConnectToDbg).
>The other three threads are all in ntdll!LdrAccessResource.
>
>How do I get to urge the debugger to go to the place in MY application
>code?
As I said, your code is probably executing in thread 1. From the above,
it is stopped in an NT dll which does not have any real symbol
information. You should still be able to set breakpoints but the
stack may or may not be in a state that will allow you to get
a backtrace.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -