[quoted text, click to view] > 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
>
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] > So, how do I get vs2005 to work in step 8? The bin\release dir has the .exe
> and the .pdb file.
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] > 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?
>
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/]