C# 2010 debug error message

Question

When I am debugging a C# 2010 application  from my visual studio.net 2010 professional ide, and I get messages like the following:

this Cannot obtain value of local or argument '<this>' as it is not available at this instruction pointer, possibly because it has been optimized away. Damport.DImportDataContext fileOrServerOrConnection Cannot obtain value of local or argument 'fileOrServerOrConnection' as it is not available at this instruction pointer, possibly because it has been optimized away. string mapping Cannot obtain value of local or argument 'mapping' as it is not available at this instruction pointer, possibly because it has been optimized away. System.Data.Linq.Mapping.MappingSource

This kind of error message occurs in different sections of the code. Some sections I do not have this problem.

Basically when this kind of error message occurs, I can not see the value in different variables. Thus can you tell me what I can do so that I can see the value of the variables when this error occurs?

Answer 1

This occurs if you are debugging through code that is not built as debug.  In the build combo at the top of VS make sure you have Debug selected as the configuration.  Then any code that you wrote for the project will step through just fine.  Code that you step through that isn't in the project can generate the above message.  The this pointer is only valid when stepping through instance methods of classes so it is not always available nor is it generally available in release builds.

The this window may not be that useful to you.  Consider using the Autos and/or Locals window instead.  They all have the same requirements though - must be your code, must be built in debug configuration, must start the debugger using F5 or toolbar.

Michael Taylor - 7/7/2012
http://msmvps.com/blogs/p3net

Answer 2

Thank your for your answer!

I have the following additional questions:

1. Your comment, "This occurs if you are debugging through code that is not built as debug.". Does that mean some code can be debugged while other code values can not be debugged? Can you explain how that is possible?

2. Your comment, "Code that you step through that isn't in the project can generate the above message". So you are saying that if my main project calls another project, I may not be able to step through code in the 'called project'? If this is the case, how can I make the values in the 'called project' be available so that I can see the values?

3. Can you explain what you mean by, "The this window may not be that useful to you.  Consider using the Autos and/or Locals window instead."? Use are just saying I should use the autos or local windows instead?

4. When you say, "must be your code", are you saying that I can not step through code that is generated by the .net framework? (I know that I have stepped through code that is generated by the .net framework since I set a debug feature to allow that type of debugging.)

Answer 3

1) If you have the source code (not the binaries), VS can find the source and the binary was built with a debug configuration then it'll work.  Otherwise it won't.

2) To clarify a project is something you load in VS as part of your solution.  It is not some assembly you are referencing.  Provided you build your code with the debug configuration you will be able to walk through the source code for any project in the solution.  Assemblies that you are referencing that are not part of the solution may or may not be steppable depending upon whether they were built with debug or not and whether the associated PDB is available.  VS uses the PDB to step through binaries so without it very little works.  Debug configurations have large PDB files (generally MBs in size).

3) Just a suggestion that the Autos/Locals windows may be more useful to you than the This window.  They all show the same data (just different scopes) and all work the same way.

4) You cannot step through .NET framework code unless you have the .NET reference source installed.  There are entire blogs about how to get this set up but it still is tricky.  For a novice it is not worth the effort trying to figure out and rarely useful so don't worry about it.  The same applies to non-framework assemblies that you might also be using such as from third-party components.  The only code you generally step through is your own code (aka the code in the projects that are loaded by your solution).

For your problem ensure you are using the Debug configuration and that you are looking only at code that is part of the solution and you should be fine.  The permutations about what could be wrong with code outside this area is too large to try to explain.  Sometimes the debugger can show you information and sometimes it can't.  It is not an indication that your code is wrong.  Basically if the code is in your project, compiled with Debug and you're debugging it via VS then it should work.  Everything else is iffy as far as what VS will show.

Answer 4

Is there a possiblity that I setup one of the following options incorrectly?

For example, I have the following set;

debug-->options and settings-->debugging-->general-->unchecked enabled just my code. Before I did that, I did not get the code to bit the breakpoints. The breakpoints were missed.

Could my problem be related to some option I set incorrectly?

Also my workstation was set to think visual studio 2008 is the default rather than visual studio 2010. Would that make some kind of a difference?

Answer 5

There aren't any options that would cause the message you're getting.  The message you get from the debugger is a common message when you are stepping through code that is not built for debugging (aka not using the Debug configuration).  Except for the fact that you can't see some of the values it is harmless and has no impact on the behavior of the actual code.

The option you mentioned specifies that the debugger should silently ignore code that you didn't write (aka code that isn't in the project).  This is provided because folks can get overwhelmed when stepping through code as they get thrown into code they didn't write.  Most experienced folks leave it unchecked because we want to step into code that isn't ours (such as the framework).

The default version of VS isn't relevant.

Please confirm what configuration and platform you are building.  Please also confirm that you are getting this message when you are stepping through code that resides in a project that you are actively debugging.

Answer 6

I am working with visual studio.net 2010 professional version and using the 'any cpu'otopn. I do not select X86 or any other option. I am getting this error message when I am stepping through the code I want to actively debug. 

Answer 7

Any CPU is the platform.  The configuration will be Debug or Release by default.  You want to use Debug.  And the code you're stepping through is in the project you have set as the startup project?

Michael Taylor - 7/11/2012
http://msmvps.com/blogs/p3net

Answer 8

I do have a startup project.

Answer 9

That wasn't really the question I asked.  You have to have a startup project in order to debug.  The question is "is the code you are trying to step through contained in the project that you have set as the startup project"?    But before getting there please confirm that you are building a debug configuration by verifying the Configuration combo box is set to Debug and not Release.  Just to be safe also use Configuration Manager to confirm that you are building a Debug configuration of the project(s) in question because a solution's configuration/platform settings can differ from each projects'.

If the code is part of the startup project then verifying the project configuration is sufficient.  If the code is part of another project that is used by your startup project then confirm that you added the reference as a project reference rather than as a binary reference.  If you aren't sure then remove the reference and add it back via Add References but confirm that you do so by selecting the project from the list of projects loaded in the solution and not by manually browsing for the assembly on disk.  Also confirm that the project is being built via the Debug configuration in Configuration Manager.

If the code is not part of any of the projects in the solution then the behavior you're seeing is likely correct as the actual source is not available to the debugger so it is hydrating it from the underlying IL and the IL is optimized.

Answer 10

In response to your questions:

1. The question is "is the code you are trying to step through contained in the project that you have set as the startup project"? Yes it is.

2. Yes I am using the Configuration Manager to confirm that I am building in debug mode.

3. I code I want tio step through is part of the project I call the startup project.

4. The project is built  via the Debug configuration in Configuration Manager

Answer 11

Rereading your original post again I'm going to hypothesize about what you're doing.  Please confirm.  But first, what window are you using to view the variable values - Autos, Locals, This, Watch, etc?

I suspect you're using the watch window and adding some variables to or or perhaps pinning the data tip that appears when you hover over a variable.  When you do this the variables you are viewing are local variables.  When you leave the scope the variable values will no longer be available.  Additionally if you switch to a different stack frame (such as when you call a function) then the variables (while still in memory) will not be available because the current stack frame is what is used to populate the various windows.  So as the frame changes what variables are accessible will also change.  This sort of lines up with some of the messages you're posting:

"this cannot obtain" - indicates you're trying to view the 'this' object but you are not in the frame of one of the methods of 'this'.

"Damport.DImportDataContext.fileOrServer..." - appears to be a field of a data context class which you won't have access to unless you are stepping through the code for a method in DImportDataContext.

"mapping" - appears to be a parameter (for MappingSource perhaps) but you are no longer in the method where the parameter was used so the variable is gone.

Furthermore if you are using deferred execution constructs like Task or LINQ then variables you reference in the code block will not necessarily be available because of closure (read up on lambdas if you're curious).  Finally I noticed you mentioned DataSource.  Does this mean your app is a web site?  If so then you are dealing with compiler generated code.  Code that is contained in the markup file directly won't get compiled until runtime and then it uses the flag in the web.config to determine whether it is debug or release.

Answer 12

The following is in response to your questions:

1. I am using the immediate window, the locals, and the watch windows. I never used a 'this' window. is there such a thing as a 'this' window?

2. I am assuming the variables are in scope the entire time you have stepped into code in a called method correct?

3. When I am looking at when a varirable actually gets a value set, I can not even see the value at that time.

4. I am bascially just trying to step through code in one method.

5. I am questioning what you mean by ' the 'this' object but you are not in the frame of one of the methods of 'this'? I am guessing you mean the 'current' method I am stepping through the code.

6. This is correct, " "Damport.DImportDataContext.fileOrServer..." - appears to be a field of a data context class which you won't have access to unless you are stepping through the code for a method in DImportDataContext.

I can not step through any code unless I set the debug general option to 'just my code'.

7. the code I am referring to is used in alot of linq to sql statements.

8. You are correct here, " Does this mean your app is a web site? 

This is a web app that is being tested on iis 7 on my local workstation. When I test using cassini (the default web server), I do not have any problems.I have this problem when I try to debug using iis7.

9. This is in reference to the following, "If so then you are dealing with compiler generated code.  Code that is contained in the markup file directly won't get compiled until runtime and then it uses the flag in the web.config to determine whether it is debug or release."

When you say the  the flag in the web.config to determine whether it is debug or release, are you referring to compilationdebug="true"? If so, that option is not working for me when I am using iis7. Do you know what other option I should be using? If not, can you tell me what option you are referrring to?

Answer 13

1) Yes there is a 'this' window but the rest of your answers clarify what is going on so we'll leave it at that.

2) The variables are in scope only while the method they are defined in is the current stack frame.  If method A calls method B then while executing method B the local variables in method A (another stack frame) are not visible.  In the Call Stack window you can get a view of the stack frames.  For each stack frame if you double click on it then the variable windows will reset their scope to the specified frame.  Hence you can see the variables in previous frames by changing the active frame in the Call Stack window.  If this is confusing then don't worry about it.  It is an advanced topic.  Suffice to say that only while you're in the actual method body will that method's variables be visible.

3) See below.

4) See below.

5) See below.

6) Ok

7) Code in LINQ statements is converted at compile time to a method in a hidden, compiler-generated type.  The result is that debugging code in a LINQ statement can be iffy.  Of course if the LINQ statement just calls a method then debugging the method is fine but the LINQ expression itself is more difficult.

8) That explains a lot actually and is the source of your issues.

9) compilation debug="true" determines whether the ASP.NET generated code for the site is debug or release.  This is normally set true while debugging and false in production.

The problem is that you're trying to use IIS to debug.  The reason why webdev was created was because debugging via IIS requires administrative privileges along with some hotfixes to VS.  In most cases it is not worth the effort.  In the cases it does work though you'll run into the very problems you're seeing where some code can be debugged and others can't.  The problem is that the debugger cannot fully interact with IIS (which is a standalone service) so the debugging is limited.  There are lots of articles about getting debugging working correctly in IIS if you are inclined to do so but I suspect it'll take longer to get it figured out then to actually debug your problem.

My first question would by why you're trying to debug via IIS to begin with.  You should debug via WebDev as this is the easiest approach.  There are a few cases where WebDev behaves differently than IIS but this shouldn't cause problems except for advanced scenarios (like custom handlers or routing).  In the few cases where WebDev just won't work for you then move up to IIS Express.  This free program works with VS2010 SP1+ and is a replacement for WebDev.  IISX is the IIS engine restricted to prevent security holes while providing all the functionality of the full IIS.  It is the default for web apps going forward.  Since it is an app that starts up only when needed it is secure, requires no resources when not being used, can be run without admin privileges and allows for the full debugging experience.  I would recommend that you use IISX to debug your app and forget about IIS altogether.

Answer 14

Thanks for your answers!

I do have the following additional questions/comments:

1. My boss told me to debug using iis7 so I can see where problems can arise before they are deployed to production. Until a week or two ago, there was no place for me 'test' the web form application to see what problems could occur. Now there is a place for me to remote into the iis 7 test server (that is compatible with iis 6) and debug the code. However on this remote 'test' server that I can step through the code, will I have the same issues that I encountered using iis 7 on my work station? If so, is there away to get around the problem? If not, how would you recommend that I can step through the code On this remote server?

2. On the remote 'test' server, if I set the compilation debug="true" in the web.config file, will I be able to step through the code? Do I need to set another option?

3. I had thought of using IIS Express. However I did not think IIS Express would be accesible for iis 7 that needs to be compatible with iis6 since it is a newer tool. Am I wrong?

4. in your statement, "IISX is the IIS engine restricted to prevent security holes while providing all the functionality of the full IIS", can IISx find the security holes for me when stepping through code?

5. When I was trying to step though the .net code that was generated at run time, I was getting compile errors. The compile errors pointed to an assembly that was not loaded in the application. The .net framework would not let me step through this code. The only way I could step through the code was to set the debug option, to just my code. This assembly is definitely not used any longer.
When I was trying to step through the code this way, I logged onto the application the following way:
a. I would open visual studio.net 2010,
b. i selected file,
c. open website,
d. selected local iis,
e. I then selected the local iis I wanted to work with.
f. from here I had compile errors.

To solve this problem in the future, I am trying to decide what to do. Do I need to remove the .net code that is no longer used?
If not, what would you suggest I do?

Also if I would chose the debug and then attach to process and pick the process I want to attach to, would my problem go away?
if not, what would you suggest i do?

Answer 15

1) Remote IIS boxes are at the extreme end of what is debuggable. To debug a site on one you'd need to run VS as admin locally, have admin privileges on the IIS box and everything would need to be configured correctly.  Debugging on a remote IIS box is almost always a last resort because the overhead is not worth the gains.  In general a site will run correctly on IIS if it runs correctly on WebDev.  There are exceptions such as security and custom handlers.  But in these cases we escalate up the chain from WebDev to our local IIS machine and then, only if absolutely necessary, a remote IIS machine.  I've only seen a handful of occasions where a remote IIS debug was necessary and it is almost always related to an environmental or configuration problem so logging is a better choice. 

However you should most definitely test your code on the remote IIS box but testing doesn't require that you be able to debug your code.  In fact debugging your code on the remote machine is generally a bad idea because your code behaves differently when debugged vs when running in a production environment.

2) In general stepping through the code on the remote IIS box isn't going to work well.  It depends upon a lot of factors but in general expect to see the behavior you're seeing now.  Of course it won't work at all unless you have the necessary admin privileges.

3) IIS compatibility is rarely a problem that you need to worry about.  Debug and get your site working with IISX and then run it on a true IIS6 server to verify there are no lingering issues.

4) IISX doesn't find security holes.  It just has a smaller attack surfaces so it doesn't unnecessarily expose your machine to the security issues that a normal IIS box would have.

5) I don't understand what problem you're having.  You aren't going to be able to step through all the code while running against IIS.  In general it isn't necessary anyway.  The only code you might need to step through is your own code.  The Just My Code option (when set) silently skips over code that isn't yours.  It saves you from being thrown into code that you didn't right.  This would include some of the code that supports your pages since ASP.NET dynamically generates a lot of code.

Attaching to a process is no different than starting the process in the debugger as far as debugging your app is concerned.  The problem is that you can't get the full debugging experience while debugging IIS.  It just isn't going to happen.

Answer 16

When I developed my web form pages, everything was working in cassini. However when I was running the web form application on iis7, some unexpected error messages occurred. I did not know what was causing them.

A contractor came in and told me my default connection strings were being overriden. This was caused by dragging a table onto an existing linq to sql (*.dbml) file. I had no way of knowing what what causing the problem since I could not debug.

Another problem that was fine on cassini but was incorrect in iis7 was the default connection string that .net added to the web config file. I needed to add the user name and password to the connection string. I found this out by placing specific code in a try catch block.

These are the kind of errors I would like to be able to debug.

Answer 17

Both of the problem you had were configuration issues.  You would have these same problems in WebDev or IISX.  You could take the binaries (and configs) from the remote IIS box, put them back on your local machine and you'd have the same issues.  Debugging isn't really the way to detect these types of problems.

You can use IIS Manager to view and edit the app settings and connection strings without looking at the config file directly.  Whenever you move a web site to another machine you will generally need to verify the config entries as they are almost always different between dev and production.  The areas that are generally modified include app settings, connection strings, WCF service endpoints and the compilation settings. 

Whenever an app fails to connect to the DB the first thing you should confirm is the connection string.  Then security.  To easily diagnose these issues you can do one of several things:

1) Go to the IIS machine and connect to the site through the browser on the IIS machine.  By default the local browser of IIS will get the detailed exception information, including callstack.  This will almost always tell you everything you need to know.  In this specific case you would have seen that the connstring was wrong and you wouldn't have had to debug.  The only permissions you'd need is local logon rights to the IIS machine.

2) Alternatively edit the config file and turn custom errors off (it is on for non-local browsers by default).  Then you can use any browser to connect to the IIS site.  You'll get the detailed exception information.  In general for dev servers you'll want to leave this off so that you can get all the important information without debugging.  However in production servers you will want to leave custom errors on because you don't want people getting any info about your site.

So, in summary, these aren't problems that are specific to a remote IIS machine but rather standard configuration problems that you don't really need to debug.  All you need is either a logging infrastructure (which .NET has out of the box) or detailed error info by disabling custom errors.  These types of problems will occur on WebDev and IISX as well so the overhead of remote debugging of IIS isn't needed.

Michael Taylor - 7/19/2012
http://msmvps.com/blogs/p3net

Answer 18

Thank you very much for all your help!

Hopefully in the near future I will be able to return the same favor by helping others!