Prev: Heap corruption in CThreadSlotData::SetValue()?
Next: IHTMLInputElement::put_value doesn't set editbox value?
From: Rahul on 4 May 2010 02:50
Hi All,

We were trying to do remote debugging for a VC++ application
(developed in VSTS 2008), The remote machine does not have any
debugger installed so the default crash dialog just shows two buttons
"Send Report" and "Close Program".
We have installed the remote debugger on Remote machine and when the
program crashes and the crash dialog comes we attach the program with
the VC++ running on other machine, but there we are not able to see
the stack. When we say "Pause" then a message box comes saying "The
program is deadlocked, no thread is running".
We found that if the remote machine also has VSTS installed in which
case the default crash dialog also shows one more button "Debug" then
after attaching the crashed application to the VC++ on another machine
if we click on "Debug" on the remote machine (Where the app crashed)
then we could see the stack.

I was wondering if there is any way to see the stack from the remote
machine (on which there is no debugger installed).
Please let me know if there is any other way to see the stack in the
above scenario.

Thanks in advance
Rahul
From: Woody on 4 May 2010 13:09
If you can run the pgm using the remote debugger, the stack should be
visible on a crash. By "remote debugger", I mean VS is installed on
the host machine, MSVSMON is installed on the remote machine, and the
app is started in the VS debugger on the host. In general, the .pdb
needs to be available to the debugger, and the name of the .pdb must
be the same as it was when the executable is created.

You didn't mention what happened first when you saw the crash. That is
important to understanding how to proceed.

The "deadlocked" message you got usually means threads are waiting for
something, such as user input.
From: Rahul on 4 May 2010 23:28
On May 4, 10:09 pm, Woody <ols6...(a)sbcglobal.net> wrote:
> If you can run the pgm using the remote debugger, the stack should be
> visible on a crash. By "remote debugger", I mean VS is installed on
> the host machine, MSVSMON is installed on the remote machine, and the
> app is started in the VS debugger on the host. In general, the .pdb
> needs to be available to the debugger, and the name of the .pdb must
> be the same as it was when the executable is created.
>
> You didn't mention what happened first when you saw the crash. That is
> important to understanding how to proceed.
>
> The "deadlocked" message you got usually means threads are waiting for
> something, such as user input.

Hi Woody,

I had discovered that if I start the program inside teh debugger
itself then I get the crash.
But the progra was started directly on the remote machine and I attach
it only when it crashes on the remote machine. When the crash happens
I get a dialog box showing "Close Program" and "Send Report" buttons.
At this point I attach it to the debugger on host machine.

You are right, the program shows deadlock state because the threads
are waiting for the user to click on any of the two mentioned buttongs
on the crash dialog box.
Now my problem is, If I click any of the buttons after attaching it to
the debugger then the program silently exits, without breaking in the
debugger.

If there would have been a "Debug" button in the crash dialog box
(Which comes when the remote machine alsso has VC++ installed) then I
could have clicked "Debug" on the remote machine and then it would
have shown me the stack on the host machine debugger.
I want to achieve this without installing VC++ on the remote machine.

So my problem is, How do I continue the waiting threads and break them
inside the host machine debugger after crash.

Thanks in advance
Rahul
From: Woody on 5 May 2010 22:39
On May 4, 8:28 pm, Rahul <rsharma.ch...(a)gmail.com> wrote:
> I had discovered that if I start the program inside teh debugger
> itself then I get the crash.

If you can make it crash when you start inside the debugger, you
should just find the cause of the crash and fix the code. That is the
most desirable choice.

Next most desirable is to set up remote debugging, as I described
using MSVSMON on the remote machine.

If you are unable to do either of these for some reason, you can set
up the remote machine to create a crash dump using Dr Watson. Or, you
can run Process Explorer on the remote machine after the crash and see
the stack for each thread. To be useful, you'll need to put the .pdb
on the remote machine so PE can find it.

I am also assuming you looked over your code for possible causes of
the crash, given the history of operations you did on the remote
machine before it crashed.
From: Rahul on 5 May 2010 23:26
> If you can make it crash when you start inside the debugger, you
> should just find the cause of the crash and fix the code. That is the
> most desirable choice.

Yes surely it is the most desirable choice, but the crashes are non-
reproducible ones and happens quite rarely (e.g. after working for 2-3
days continuously) but thats also not sure that it will happen.


> If you are unable to do either of these for some reason, you can set
> up the remote machine to create a crash dump using Dr Watson. Or, you
> can run Process Explorer on the remote machine after the crash and see
> the stack for each thread. To be useful, you'll need to put the .pdb
> on the remote machine so PE can find it.

PE also shows the same thing, the threads are in waiting stage with
some call to kernel32::waitForMultipleObject", its again the same
thing which I get after attaching with the debugger.
crash dump looks a better idea


> I am also assuming you looked over your code for possible causes of
> the crash, given the history of operations you did on the remote
> machine before it crashed.

Yes we did, but our code is too huge (2 million LOC) to suspect any
portion of it :-)

Thanks
Rahul
 |  Next  |  Last
Pages: 1 2
Prev: Heap corruption in CThreadSlotData::SetValue()?
Next: IHTMLInputElement::put_value doesn't set editbox value?