debugging a remote process using windbg
| Author |
Message |
|
Edward Cha
#1 / 10
|
 debugging a remote process using windbg Hi there,
I was wondering if anybody has used windbg to debug a
process running on a remote server. I have copied a debug
binary, along with the .pdb, to a remote server. From my
local machine, that contains the src files, I want to
debug the process on the remote server. Everything seems
ok, except that when I break, and view local vars, I can't
see info for object variables. It seems like bools, ints,
etc. display the correct values, but I can't see or expand
variables that are objects. It does list them, but the
value says <No information found error>.
I tried to run the process locally. When I
choose "Connect to remote session..." menu option
(eventhough the process is actually on the local machine),
I specify the name of my local machine, it works, and the
de{*filter*} is able to pick up the correct info and display
all variables properly.
Has anyone run into this? What am I doing wrong?
Thanks,
Ed
|
| Sat, 25 Jun 2005 09:26:03 GMT |
|
 |
|
Jian-Shen Lin[MSF
#2 / 10
|
debugging a remote process using windbg All the symbol and source shall deploy in the traget machine (the
application running machine)
Your remote machine just use remote seesion to connect with the target
machines,
you can use following command in your target machine
0:000> .server tcp:port=600
Then it will tell your server start as follow:
Server started. Client can connect with any of:
0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
Then your client can connect it and use it,
Best Regards
Jian Shen
This posting is provided "AS IS" with no warranties, and confers no rights.
|
| Sat, 25 Jun 2005 20:23:09 GMT |
|
|
|
Edward Cha
#3 / 10
|
debugging a remote process using windbg Quote: >-----Original Message-----
>All the symbol and source shall deploy in the traget
machine (the
>application running machine)
So you mean I need to copy the source to the remote machine? Is there a way to debug the remote process on my local machine that contains the code that the remote process was built from? For example, let's say I have a customer issue. I give
them a debug build. Connect to the remote server using
WinDbg. The code resides on my local machine because I
don't want to copy code to the customer's machine. Is
there any way to debug this?
It seems to work...almost. I can view the threads and
call stack, and variables show up in the variables
window. But I am unable to see the values for variables
that are objects (built in types such as boolean, int,
etc. seem to be ok).
Quote: >Your remote machine just use remote seesion to connect
with the target
>machines,
>you can use following command in your target machine
>0:000> .server tcp:port=600
>Then it will tell your server start as follow:
>Server started. Client can connect with any of:
>0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
>Then your client can connect it and use it,
>Best Regards
>Jian Shen
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>.
|
| Sun, 26 Jun 2005 01:49:51 GMT |
|
|
|
Pavel Lebedinsk
#4 / 10
|
debugging a remote process using windbg I think you can use the process server (dbgsrv.exe) to do that. When you connect to a process server, the actual de{*filter*} is running on your machine, not on the remote box where dbgsrv runs. Accordingly, it will look for symbols and sources on your local machine. See de{*filter*} docs for details on using dbgsrv.
If that doesn't work, try posting your question to
microsoft.public.windbg newsgroup.
Quote:
> >-----Original Message-----
> >All the symbol and source shall deploy in the traget
> machine (the
> >application running machine)
> So you mean I need to copy the source to the remote
> machine? Is there a way to debug the remote process on my
> local machine that contains the code that the remote
> process was built from?
> For example, let's say I have a customer issue. I give
> them a debug build. Connect to the remote server using
> WinDbg. The code resides on my local machine because I
> don't want to copy code to the customer's machine. Is
> there any way to debug this?
> It seems to work...almost. I can view the threads and
> call stack, and variables show up in the variables
> window. But I am unable to see the values for variables
> that are objects (built in types such as boolean, int,
> etc. seem to be ok).
> >Your remote machine just use remote seesion to connect
> with the target
> >machines,
> >you can use following command in your target machine
> >0:000> .server tcp:port=600
> >Then it will tell your server start as follow:
> >Server started. Client can connect with any of:
> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
> >Then your client can connect it and use it,
> >Best Regards
> >Jian Shen
|
| Sun, 26 Jun 2005 10:30:29 GMT |
|
|
|
Edward Cha
#5 / 10
|
debugging a remote process using windbg Isn't dbgsrv basically the same as running windbg, except
windbg has a GUI?
Quote: >-----Original Message----- >I think you can use the process server (dbgsrv.exe) >to do that. When you connect to a process server, >the actual de{*filter*} is running on your machine, not >on the remote box where dbgsrv runs. Accordingly, >it will look for symbols and sources on your local >machine. >See de{*filter*} docs for details on using dbgsrv.
>If that doesn't work, try posting your question to
>microsoft.public.windbg newsgroup.
>> >-----Original Message-----
>> >All the symbol and source shall deploy in the traget
>> machine (the
>> >application running machine)
>> So you mean I need to copy the source to the remote
>> machine? Is there a way to debug the remote process on
my
>> local machine that contains the code that the remote
>> process was built from?
>> For example, let's say I have a customer issue. I give
>> them a debug build. Connect to the remote server using
>> WinDbg. The code resides on my local machine because I
>> don't want to copy code to the customer's machine. Is
>> there any way to debug this?
>> It seems to work...almost. I can view the threads and
>> call stack, and variables show up in the variables
>> window. But I am unable to see the values for variables
>> that are objects (built in types such as boolean, int,
>> etc. seem to be ok).
>> >Your remote machine just use remote seesion to connect
>> with the target
>> >machines,
>> >you can use following command in your target machine
>> >0:000> .server tcp:port=600
>> >Then it will tell your server start as follow:
>> >Server started. Client can connect with any of:
>> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
>> >Then your client can connect it and use it,
>> >Best Regards
>> >Jian Shen
>.
|
| Mon, 27 Jun 2005 08:04:07 GMT |
|
|
|
Edward Cha
#6 / 10
|
debugging a remote process using windbg Quote: >-----Original Message----- >I think you can use the process server (dbgsrv.exe) >to do that. When you connect to a process server, >the actual de{*filter*} is running on your machine, not >on the remote box where dbgsrv runs. Accordingly, >it will look for symbols and sources on your local >machine. >See de{*filter*} docs for details on using dbgsrv.
>If that doesn't work, try posting your question to
>microsoft.public.windbg newsgroup.
Do you know of a newserver that allows posting. I can't seem to find one with this newsgroup that allows posting to it. Quote:
>> >-----Original Message-----
>> >All the symbol and source shall deploy in the traget
>> machine (the
>> >application running machine)
>> So you mean I need to copy the source to the remote
>> machine? Is there a way to debug the remote process on
my
>> local machine that contains the code that the remote
>> process was built from?
>> For example, let's say I have a customer issue. I give
>> them a debug build. Connect to the remote server using
>> WinDbg. The code resides on my local machine because I
>> don't want to copy code to the customer's machine. Is
>> there any way to debug this?
>> It seems to work...almost. I can view the threads and
>> call stack, and variables show up in the variables
>> window. But I am unable to see the values for variables
>> that are objects (built in types such as boolean, int,
>> etc. seem to be ok).
>> >Your remote machine just use remote seesion to connect
>> with the target
>> >machines,
>> >you can use following command in your target machine
>> >0:000> .server tcp:port=600
>> >Then it will tell your server start as follow:
>> >Server started. Client can connect with any of:
>> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
>> >Then your client can connect it and use it,
>> >Best Regards
>> >Jian Shen
>.
|
| Mon, 27 Jun 2005 07:59:56 GMT |
|
|
|
Pavel Lebedinsk
#7 / 10
|
debugging a remote process using windbg No, dbgsrv is different. When you run a de{*filter*} with -server option, all processing occurs on the server, the clients are simply terminals that pass commands to and from the de{*filter*}. Which means that symbols and sources have to be installed on the server machine. With dbgsrv, most of the processing occurs on the client.
In this case symbols and sources have to be on the client
machine because that's where the actual de{*filter*} runs.
Quote:
> Isn't dbgsrv basically the same as running windbg, except > windbg has a GUI? > >-----Original Message-----
> >I think you can use the process server (dbgsrv.exe)
> >to do that. When you connect to a process server,
> >the actual de{*filter*} is running on your machine, not
> >on the remote box where dbgsrv runs. Accordingly,
> >it will look for symbols and sources on your local
> >machine.
> >See de{*filter*} docs for details on using dbgsrv.
> >If that doesn't work, try posting your question to
> >microsoft.public.windbg newsgroup.
> >> >-----Original Message-----
> >> >All the symbol and source shall deploy in the traget
> >> machine (the
> >> >application running machine)
> >> So you mean I need to copy the source to the remote
> >> machine? Is there a way to debug the remote process on
> my
> >> local machine that contains the code that the remote
> >> process was built from?
> >> For example, let's say I have a customer issue. I give
> >> them a debug build. Connect to the remote server using
> >> WinDbg. The code resides on my local machine because I
> >> don't want to copy code to the customer's machine. Is
> >> there any way to debug this?
> >> It seems to work...almost. I can view the threads and
> >> call stack, and variables show up in the variables
> >> window. But I am unable to see the values for variables
> >> that are objects (built in types such as boolean, int,
> >> etc. seem to be ok).
> >> >Your remote machine just use remote seesion to connect
> >> with the target
> >> >machines,
> >> >you can use following command in your target machine
> >> >0:000> .server tcp:port=600
> >> >Then it will tell your server start as follow:
> >> >Server started. Client can connect with any of:
> >> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
> >> >Then your client can connect it and use it,
> >> >Best Regards
> >> >Jian Shen
> >.
|
| Tue, 28 Jun 2005 08:16:53 GMT |
|
|
|
Edward Cha
#8 / 10
|
debugging a remote process using windbg Oh, very interesting. Can you give me an example of how to do this? Does this mean I have to do everything command line? Ed
Quote: >-----Original Message----- >No, dbgsrv is different. When you run a de{*filter*} with >-server option, all processing occurs on the server, >the clients are simply terminals that pass commands to and >from the de{*filter*}. Which means that symbols and sources >have to be installed on the server machine. >With dbgsrv, most of the processing occurs on the client.
>In this case symbols and sources have to be on the client
>machine because that's where the actual de{*filter*} runs.
>> Isn't dbgsrv basically the same as running windbg,
except
>> windbg has a GUI?
>> >-----Original Message-----
>> >I think you can use the process server (dbgsrv.exe)
>> >to do that. When you connect to a process server,
>> >the actual de{*filter*} is running on your machine, not
>> >on the remote box where dbgsrv runs. Accordingly,
>> >it will look for symbols and sources on your local
>> >machine.
>> >See de{*filter*} docs for details on using dbgsrv.
>> >If that doesn't work, try posting your question to
>> >microsoft.public.windbg newsgroup.
>> >> >-----Original Message-----
>> >> >All the symbol and source shall deploy in the traget
>> >> machine (the
>> >> >application running machine)
>> >> So you mean I need to copy the source to the remote
>> >> machine? Is there a way to debug the remote process
on
>> my
>> >> local machine that contains the code that the remote
>> >> process was built from?
>> >> For example, let's say I have a customer issue. I
give
>> >> them a debug build. Connect to the remote server
using
>> >> WinDbg. The code resides on my local machine
because I
>> >> don't want to copy code to the customer's machine.
Is
>> >> there any way to debug this?
>> >> It seems to work...almost. I can view the threads
and
>> >> call stack, and variables show up in the variables
>> >> window. But I am unable to see the values for
variables
>> >> that are objects (built in types such as boolean,
int,
>> >> etc. seem to be ok).
>> >> >Your remote machine just use remote seesion to
connect
>> >> with the target
>> >> >machines,
>> >> >you can use following command in your target machine
>> >> >0:000> .server tcp:port=600
>> >> >Then it will tell your server start as follow:
>> >> >Server started. Client can connect with any of:
>> >> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
>> >> >Then your client can connect it and use it,
>> >> >Best Regards
>> >> >Jian Shen
>> >.
>.
|
| Tue, 28 Jun 2005 08:58:05 GMT |
|
|
|
Pavel Lebedinsk
#9 / 10
|
debugging a remote process using windbg You can find some examples in the de{*filter*}s.chm file that is installed with the de{*filter*}s. No, you don' t have to use command line de{*filter*}s -
windbg should work just fine. In fact, windbg and cdb/ntsd
are simply different UIs on top of the same de{*filter*} engine.
(Actually, there are some minor differences. For example,
WinDbg has an option to search for source files on the local
machine (.lsrcpath). Again, this is all described in the docs)
Quote:
> Oh, very interesting. Can you give me an example of how > to do this? Does this mean I have to do everything > command line? > Ed
> >-----Original Message-----
> >No, dbgsrv is different. When you run a de{*filter*} with
> >-server option, all processing occurs on the server,
> >the clients are simply terminals that pass commands to and
> >from the de{*filter*}. Which means that symbols and sources
> >have to be installed on the server machine.
> >With dbgsrv, most of the processing occurs on the client.
> >In this case symbols and sources have to be on the client
> >machine because that's where the actual de{*filter*} runs.
> >> Isn't dbgsrv basically the same as running windbg,
> except
> >> windbg has a GUI?
> >> >-----Original Message-----
> >> >I think you can use the process server (dbgsrv.exe)
> >> >to do that. When you connect to a process server,
> >> >the actual de{*filter*} is running on your machine, not
> >> >on the remote box where dbgsrv runs. Accordingly,
> >> >it will look for symbols and sources on your local
> >> >machine.
> >> >See de{*filter*} docs for details on using dbgsrv.
> >> >If that doesn't work, try posting your question to
> >> >microsoft.public.windbg newsgroup.
> >> >> >-----Original Message-----
> >> >> >All the symbol and source shall deploy in the traget
> >> >> machine (the
> >> >> >application running machine)
> >> >> So you mean I need to copy the source to the remote
> >> >> machine? Is there a way to debug the remote process
> on
> >> my
> >> >> local machine that contains the code that the remote
> >> >> process was built from?
> >> >> For example, let's say I have a customer issue. I
> give
> >> >> them a debug build. Connect to the remote server
> using
> >> >> WinDbg. The code resides on my local machine
> because I
> >> >> don't want to copy code to the customer's machine.
> Is
> >> >> there any way to debug this?
> >> >> It seems to work...almost. I can view the threads
> and
> >> >> call stack, and variables show up in the variables
> >> >> window. But I am unable to see the values for
> variables
> >> >> that are objects (built in types such as boolean,
> int,
> >> >> etc. seem to be ok).
> >> >> >Your remote machine just use remote seesion to
> connect
> >> >> with the target
> >> >> >machines,
> >> >> >you can use following command in your target machine
> >> >> >0:000> .server tcp:port=600
> >> >> >Then it will tell your server start as follow:
> >> >> >Server started. Client can connect with any of:
> >> >> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
> >> >> >Then your client can connect it and use it,
> >> >> >Best Regards
> >> >> >Jian Shen
> >> >.
> >.
|
| Wed, 29 Jun 2005 06:56:45 GMT |
|
|
|
Edward Cha
#10 / 10
|
debugging a remote process using windbg Thanks, I got it working.
Quote: >-----Original Message----- >You can find some examples in the de{*filter*}s.chm file that >is installed with the de{*filter*}s. >No, you don' t have to use command line de{*filter*}s -
>windbg should work just fine. In fact, windbg and cdb/ntsd
>are simply different UIs on top of the same de{*filter*}
engine.
>(Actually, there are some minor differences. For example,
>WinDbg has an option to search for source files on the
local
>machine (.lsrcpath). Again, this is all described in the
docs)
>> Oh, very interesting. Can you give me an example of how
>> to do this? Does this mean I have to do everything
>> command line?
>> Ed
>> >-----Original Message-----
>> >No, dbgsrv is different. When you run a de{*filter*} with
>> >-server option, all processing occurs on the server,
>> >the clients are simply terminals that pass commands to
and
>> >from the de{*filter*}. Which means that symbols and sources
>> >have to be installed on the server machine.
>> >With dbgsrv, most of the processing occurs on the
client.
>> >In this case symbols and sources have to be on the
client
>> >machine because that's where the actual de{*filter*} runs.
>> >> Isn't dbgsrv basically the same as running windbg,
>> except
>> >> windbg has a GUI?
>> >> >-----Original Message-----
>> >> >I think you can use the process server (dbgsrv.exe)
>> >> >to do that. When you connect to a process server,
>> >> >the actual de{*filter*} is running on your machine, not
>> >> >on the remote box where dbgsrv runs. Accordingly,
>> >> >it will look for symbols and sources on your local
>> >> >machine.
>> >> >See de{*filter*} docs for details on using dbgsrv.
>> >> >If that doesn't work, try posting your question to
>> >> >microsoft.public.windbg newsgroup.
>> >> >> >-----Original Message-----
>> >> >> >All the symbol and source shall deploy in the
traget
>> >> >> machine (the
>> >> >> >application running machine)
>> >> >> So you mean I need to copy the source to the
remote
>> >> >> machine? Is there a way to debug the remote
process
>> on
>> >> my
>> >> >> local machine that contains the code that the
remote
>> >> >> process was built from?
>> >> >> For example, let's say I have a customer issue. I
>> give
>> >> >> them a debug build. Connect to the remote server
>> using
>> >> >> WinDbg. The code resides on my local machine
>> because I
>> >> >> don't want to copy code to the customer's machine.
>> Is
>> >> >> there any way to debug this?
>> >> >> It seems to work...almost. I can view the threads
>> and
>> >> >> call stack, and variables show up in the variables
>> >> >> window. But I am unable to see the values for
>> variables
>> >> >> that are objects (built in types such as boolean,
>> int,
>> >> >> etc. seem to be ok).
>> >> >> >Your remote machine just use remote seesion to
>> connect
>> >> >> with the target
>> >> >> >machines,
>> >> >> >you can use following command in your target
machine
>> >> >> >0:000> .server tcp:port=600
>> >> >> >Then it will tell your server start as follow:
>> >> >> >Server started. Client can connect with any of:
>> >> >> >0 - De{*filter*} Server - tcp:Port=600,Server=XXXXX
>> >> >> >Then your client can connect it and use it,
>> >> >> >Best Regards
>> >> >> >Jian Shen
>> >> >.
>> >.
>.
|
| Wed, 29 Jun 2005 09:46:28 GMT |
|
| |
|
