Debugging managed code

In desperation I have been attempting to debug managed code in a service I
have been developing. At this point the service is indeed loaded and has
been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mscorwks!ArrayList ***
*** ***
*************************************************************************
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”, and
when I do a search of the Symbols directory I see the mscorwks pdb file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”.

So, how can this be resolved?

Gary G. Little

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

If you have Visual Studio 2005 on the machine where you’re running the
code you’ll have CLR v2.0 there also. You just have to make sure to use
a matching sos (the CLR 1.0/1.1 sos that comes with the debugger
packages will not work, you have to use the sos that comes with the v2.0
CLR).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:18 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

So take the sos.dll from 2005?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:22 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

If you have Visual Studio 2005 on the machine where you’re running the
code you’ll have CLR v2.0 there also. You just have to make sure to use
a matching sos (the CLR 1.0/1.1 sos that comes with the debugger
packages will not work, you have to use the sos that comes with the v2.0
CLR).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:18 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

The simplest way is to use the sos that comes with the CLR. One way to
find this is run your managed app/service under a debugger (or attach).
Once the CLR has loaded look at the image file path for mscorwks.

0:004> lmfmmscorwks
start end module name
79e70000 7a3d1000 mscorwks
C:\windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

If your path has v2 in it, like mine does, that confirms your app is
running under CLR V2. You should then be able to do

.loadby sos mscorwks

to have the debugger go load the sos extension from the same path as the
mscorwks module.

0:004> .loadby sos mscorwks
0:004> .chain

Extension DLL chain:
C:\windows\Microsoft.NET\Framework\v2.0.50727\sos: image
2.0.50727.42, API 1.0.0, built Fri Sep 23 00:27:26 2005

You can then use sos commands (don’t specify sos, just the command, so
it gets picked up from the chain). You can also give a full path to sos
instead of using .loadby, or you can copy that sos around.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:25 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

So take the sos.dll from 2005?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:22 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

If you have Visual Studio 2005 on the machine where you’re running the
code you’ll have CLR v2.0 there also. You just have to make sure to use
a matching sos (the CLR 1.0/1.1 sos that comes with the debugger
packages will not work, you have to use the sos that comes with the v2.0
CLR).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:18 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Ah at l east I think the light dawns … So I’ll need Framework 2.0 on the
target. Why that did not sink in I’ll never know.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:35 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The simplest way is to use the sos that comes with the CLR. One way to
find this is run your managed app/service under a debugger (or attach).
Once the CLR has loaded look at the image file path for mscorwks.

0:004> lmfmmscorwks
start end module name
79e70000 7a3d1000 mscorwks
C:\windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

If your path has v2 in it, like mine does, that confirms your app is
running under CLR V2. You should then be able to do

.loadby sos mscorwks

to have the debugger go load the sos extension from the same path as the
mscorwks module.

0:004> .loadby sos mscorwks
0:004> .chain

Extension DLL chain:
C:\windows\Microsoft.NET\Framework\v2.0.50727\sos: image
2.0.50727.42, API 1.0.0, built Fri Sep 23 00:27:26 2005

You can then use sos commands (don’t specify sos, just the command, so
it gets picked up from the chain). You can also give a full path to sos
instead of using .loadby, or you can copy that sos around.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:25 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

So take the sos.dll from 2005?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:22 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

If you have Visual Studio 2005 on the machine where you’re running the
code you’ll have CLR v2.0 there also. You just have to make sure to use
a matching sos (the CLR 1.0/1.1 sos that comes with the debugger
packages will not work, you have to use the sos that comes with the v2.0
CLR).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:18 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

And of course the sos.dll is on the same machine from which I run WinDbg.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Friday, April 28, 2006 4:44 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Ah at l east I think the light dawns … So I’ll need Framework 2.0 on the
target. Why that did not sink in I’ll never know.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:35 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The simplest way is to use the sos that comes with the CLR. One way to
find this is run your managed app/service under a debugger (or attach).
Once the CLR has loaded look at the image file path for mscorwks.

0:004> lmfmmscorwks
start end module name
79e70000 7a3d1000 mscorwks
C:\windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

If your path has v2 in it, like mine does, that confirms your app is
running under CLR V2. You should then be able to do

.loadby sos mscorwks

to have the debugger go load the sos extension from the same path as the
mscorwks module.

0:004> .loadby sos mscorwks
0:004> .chain

Extension DLL chain:
C:\windows\Microsoft.NET\Framework\v2.0.50727\sos: image
2.0.50727.42, API 1.0.0, built Fri Sep 23 00:27:26 2005

You can then use sos commands (don’t specify sos, just the command, so
it gets picked up from the chain). You can also give a full path to sos
instead of using .loadby, or you can copy that sos around.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:25 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

So take the sos.dll from 2005?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:22 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

If you have Visual Studio 2005 on the machine where you’re running the
code you’ll have CLR v2.0 there also. You just have to make sure to use
a matching sos (the CLR 1.0/1.1 sos that comes with the debugger
packages will not work, you have to use the sos that comes with the v2.0
CLR).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:18 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

Okie dokie … is building on a 64 bit machine and testing a 32 bit
machine going to be an issue?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:12 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

windbg docs won’t really bear on this. Visual Studio 2005 comes with
CLR v2.0, so if you are building and running in that environment you’re
using 2.0.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

The WinDbg docs specifically call out 1.0. What 2005 is using to build I
am not sure.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 28, 2006 4:01 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Debugging managed code

It may be that the !bp command only works with private symbols and that
there isn’t anything that can be done. I will try and see if there’s a
CLR contact I can pass this on to. Asking on a CLR-related
alias/newsgroup might also work.

In your other mail you mentioned CLR version 1.0, is that the CLR
version you’re using (I thought it had been completely superseded by 1.1
a while back, and in turn 1.1 is fading now that 2.0 is out)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, April 28, 2006 9:41 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging managed code

In desperation I have been attempting to debug managed code in a service
I have been developing. At this point the service is indeed loaded and
has been started. When I set a break point I get the following:

0:004> !Bp SeaTdtSvc.exe!SeaTdtSvcWinService::OnCustomCommand
************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: mscorwks!ArrayList
***
***
***
************************************************************************
*
offset not exist for m_firstBlock
Is the framework loaded yet?
error: unexpected block size in ArrayList

From this I deduce the primary problem may be in the symbols. My symbol
path is: “SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols”,
and when I do a search of the Symbols directory I see the mscorwks pdb
file in
“C:\Symbols\mscorwks.pdb\7FA9D4C5454E4346B11ED781C22BDF462\mscorwks.pdb”
.

So, how can this be resolved?

Gary G. Little


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com