all groups > visual studio .net debugging > june 2007 >
You're in the

visual studio .net debugging

group:

attach to windows form app (release mode)


attach to windows form app (release mode) paul
6/25/2007 7:24:00 PM
visual studio .net debugging: I have simplified to this test example:

1. build a very simple c# windows form app in vs2005
2. add a button which basically causes an infinite loop w/ a few sleeps
to be nice

private void button1_Click( object sender, EventArgs e )
{
long l = 0;
while ( l < 100000000000 )
{
System.Threading.Thread.Sleep( 200 );
l++;
}
}

3. build in release mode - check that exe and pdb files exist in bin\release
4. observation: I can single step thru the app if I build and run from
within vs2005
and I can see the call stack and look at local variables (all this in
release mode)
5. next, rerun the program from outside vs2005 from the bin\release directory
6. attach to the process using vs2005
7. switch to the main gui thread using the theads window
8. observation: I can't see the stack or local variables - symbols are not
found and the debugger looks very confused - all I can see is raw assembly

So, how do I get vs2005 to work in step 8? The bin\release dir has the .exe
and the .pdb file.

One other note: windbg + sos seems to behave better - I can switch to the
gui thread and look at a good managed stack - so what's the problem w/ vs2005?

thanks,
Paul.


Re: attach to windows form app (release mode) Oleg Starodumov
6/26/2007 1:18:55 PM

[quoted text, click to view]

Here you can see the effects of JIT optimizations. If you start the application
under debugger, it by default disables JIT optimizations, and as a result you can
debug the application normally (this can be changed in Tools | Options |
Debugging | General | "Suppress JIT optimization on module load"

When you start the application without debugger, JIT optimizations are enabled,
and when you attach after that, debugging experience is limited because
the code is optimized.

[quoted text, click to view]

Approach 1: compile with /debug:full and /optimize- options (or equivalent options
in Project settings)

Approach 2: Create yourapp.ini file in the same directory with yourapp.exe file,
with the following contents:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

[quoted text, click to view]

The difference between VS2005 and WinDbg/SOS behavior is probably because
you also have Just My Code enabled. If you disable it (Tools | Options | Debugging | General |
"Enable Just My Code"), VS2005 should give you call stacks even in attach scenario
with optimizations enabled.

--
Oleg
[VC++ MVP http://www.debuginfo.com/]

Re: attach to windows form app (release mode) paul
6/26/2007 5:50:00 PM

thanks Oleg - I tried the ini approach and that worked well.

Re: attach to windows form app (release mode) paul
6/27/2007 6:58:02 AM
one nother note:

from a little experimenting, you have to create an ini file
for EACH assembly. So to turn off optimizations for assemblies
app.exe, lib1.dll and lib2.dll
create
app.ini, lib1.ini,lib2.ini
Re: attach to windows form app (release mode) Oleg Starodumov
6/28/2007 12:16:21 PM

[quoted text, click to view]

Yes, that's how it works. Each assembly should have its own .ini file.

Oleg


AddThis Social Bookmark Button