Trying to debug a controllers action method, and when I attach to process the debug icon goes hollow and says the 'current breakpoint will not be hit'
But I am doing a response.write at that point and when the page renders it does output the test text.
So that section is indeed being executed, why does debug mode not work?
Your source code may be different than the version of the corresponding process that you are attaching to. Your other process may also be built in release mode, i.e., there is no debug info.
There are a few reasons why you may see this message:
You are attached to the wrong process
You are attached to the right process but the AppDomain hasn't loaded the assembly yet
You are attached to the right process but you have forgotten to build so the source code and the PDB file are out of sync
I've noticed this happen when using reflection and dynamically loading .dll projects. If the code isn't specifically reference (i.e. you are using interface animal but dynamically loading implementations of animal such as cat/dog) it will say it won't hit the breakpoint, but actually does.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
Another reason is when you attach to the process to quickly.
For example, when I attach to Excel to debug a VSTO add-in (I am using Add-In Express), if I Build, then Start > Run > Excel, then quickly press Ctrl+Alt+P to attach to process, then press E to highlight Excel and press Enter I see this, before Excel has loaded:
The result is no Breakpoints will be hit.
However, if I give Excel a couple of seconds to load and then press Ctrl+Alt+P, notice the Title is showing:
The result is Breakpoints will be hit.
It also tells me your source code is different from the version but it is not true. I build the whole solution, then attach to process, but still it says the breakpoints won't be hit because the source code is different. Maybe it is a bug?
Related
Here is the error
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
I am writing a simple console app and the first line of code is this:
List<MyObjectModel> list = MyObjectModel.GetNonCompletedReturns();
and the code for the function is:
public static List<MyObjectModel> GetNonCompletedReturns()
{
MyObject service = new MyObject();
List<MyObject> entities =
(from recs in service.Retrieve() where select recs).ToList();
List<MyObjectModel> models = new List<MyObjectModel>();
foreach (MyObject entity in entities)
{
models.Add(BindModel(entity));
}
return models;
}
and if I try to step through the code, as soon as I get back to the main of my app and hover over the list, I get the error message that I showed.
Can anyone help?
If your project is compiled in release (with optimizations turned on), you may see this. Have you tried the DEBUG configuration?
This error fires only when you are trying to use Watch dialog during debug.
Try to use some other technique to output the variables, like Debug.WriteLine, Console.WriteLine and so on.
None of the answers solved my problem so I'm posting the solution that helped me.
"If there is to much data in the parameters then this error can occure,
a simple solution is to make an object, not a struct because that's a dataobject.
Put this object in your parameters instead of all the different variables,
normally the problem will no longer take place."
Here's a little trick just in case you want to examine some objects and you are not able to change the parameters:
I've created a call to a new temporary function, inside the function from where I was unable to watch my object. Then, inside that new function I was able to watch my object. After the job is done, just delete the function.
While it's true that the "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized" error appears when in release mode, most developers just ensure that their projects are configured to compile as a debug build. BUT to be sure that you have no release-DLL issues, you also must check the references to DLLs that are in your solution and make sure that you don't have a reference to a release-build DLL. If you find that this is the case, delete the DLL reference and then add a project reference rather than a DLL reference. The project reference will ensure that your solution references debug or release versions of the DLL as specified in your build configuration.
Note that the above advice applies, of course, to only those DLLs to which you have source code and which are built from a project in your solution.
I got this too, when I hit a NullReferenceException from a 3rd party control.
In this one case, I found that if I set a breakpoint before I hit the exception, I could then single step through the rest of the code without seeing the problem.
No idea why, but this worked for me - in this case at least.
For what it's worth, this error can also be caused by an infinite loop in a property getter (simplified version below). When the debugger attempts to evaluate the property (e.g. in the watch window) the UI will hang for a few seconds and the "Cannot evaluate expression..." error will appear for many of the other properties in the same class.
public int MyProperty
{
get
{
while (true) { }
return 0;
}
}
First make sure that you're running your code in DEBUG mode and with code optimization turned off. you can turn that off from the properties of your project.
If you made all of the above and the problem persists, then it's probably a problem with the stack having Debug.Break() on top of it. The solution for this is very easy, just press F10 to move to the next line and you should be able to evaluate the expression.
You can check this SO question for more information about this issue.
I was experiencing the same error message in the Visual Studio debugger when evaluating a linq expression.
Disabling the VS debugger config setting 'Enable Just My Code' resolved the issue for me:
To enable or disable Just My Code, choose the Tools > Options menu in
Visual Studio. In the Debugging > General node, choose or clear Enable
Just My Code.
https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code
I was having same issue in Visual Studio 2017. Going to Debug> Options> Debugging> General and checking "Suppress JIT optimization on module load(Managed only)" fixed my issue
I use breakpoints in debugging my C#/.Net programs. Very often I use many "When hit" breakpoints to display messages in the Output window and keep going, so I can examine what the program is doing while it's executing.
But I often find that after editing code my breakpoints get moved, producing spurious or incorrect results and I have to go and delete my old breakpoints and make new ones.
Searching for this on Stack Overflow I find other programmers having this problem when building in Release mode, but I'm building with a Debug configuration.
How do I make my breakpoints stay put?
Do you "share" files such as .csproj.user, .suo... with other developers of the project ?
If you are using a SCM exclude them from it, these files are not intended to be shared between different machines. To send them to another user with slightly different sources may cause this kind of funny mess.
More details about these files here :
Best practices for Subversion and Visual Studio projects
This kind of thing could also happen if you manually edit files, outside of VS (with Notepad++ for example) : try to avoid this when you want to keep breakpoints at the right place, VS doesn't like it at all.
There are many ways to examine the execution of program. Make sure you are generating full Debug Info for your project. Also check that csproj.user, .suo files aren't set as Read Only.
If these thing doesn't work, for your case I suggest you to use some console based output providing methods.
Try this one
Console.WriteLine("Currently executing this...");
The console here is the output window of VS. Select Debug from 'Show output from:'.
If you want to halt the execution, use this code
Console.WriteLine("Currently executing this...");
System.Diagnostics.Debugger.Break();
You should do conditional compilation of your code so that this doesn't get released with the final product. Console.WriteLine() will not cause any problem but System.Diagnostics.Debugger.Break() will break application.
I have a C# solution which contains a project and a class library written by somebody else. The class library gets GPS data via wifi. The project shows the processed data on a map. Now, I want to see the contents of some variables in the class library in real time for the sake of debugging.
I tried to use
System.Diagnostics.Debug.Write(value)
without success. It seems it does not do anything.
Also I tried "MessageBox.Show(value.ToString())" which was good but it stopped the wifi reading and interrupted the program as I needed to press OK button each time that it showed up.
Moreover, I added a windows form (which contained a textBox) to the class library to print the data in the textBox, however, when I wrote:
Form1.textBox1.Text = value.ToString()
It gives me this error:
Error 3 'MapNMEA.Form1.textBox1' is inaccessible due to its protection level C:\Users\john\Documents\Visual Studio 2010\Projects\new ver of map purecom\MapExplorer\MapExplorer\MapNMEA\MapNMEA\SerialPort.cs 184 27 MapNMEA
"MapNMEA" is the name of the class library. Also "MapExplorer" is the name of both solution and the project. "SerialPort.cs" is a file inside the class library in which I wrote the above code.
My question is how to show the content of those variable (they are 3,4 variables) in real time and this act should not stop the wifi reading. I need to do this as an electrician who does not know much about programming wants to check whether a GPS device sends the data to my computer correctly or not.
UPDATE 1: Actually I noticed that System.Diagnostics.Debug.Write(value) is working but as there was too many warning messages showing up in the debug window, I did not noticed it. Now, if somehow I could remove (or hide) other (warning) messages, I would see only my desired output. Do you know?
Debug.Write should be fine if you attach a listener first (Debug.Listeners.Add( new _a_listener_type() )).
Also, you should probably be aware of the AutoFlush property on the Debug class which determines whether or not Flush is automatically called.
Debug.Write should work - by default it will write to the 'Debug' window in Visual Studio if you have the debugger attached. Are you sure you're looking in the right place?
If you want to use the form approach, you need to keep track of the instance of the form which is open, and give it a public method. For example:
public void WriteDebug(string message) {
TextBox1.Text += message + Environment.NewLine;
}
Then you can call formInstance.WriteDebug(message);.
Do you run debug build? Also your code with textbox does not work, because textBox1 is non-public
I think you may not be searching the right location: Is there something preventing you from debugging on a PC first before going to a target? If not, the you should probably use the traditional way: put spies on variables, use your IDE (Visual Studio) to watch them and so on.
If you actually NEED to run on target without advanced debug tools, then you might want to take a look at some easier solutions:
log them to a text file (append or replace, whatever you need), then have a viewer opened at hand
make another non-modal form with a textbox, and call a form2.writeDbgTextBox(String) every time you need to refresh
Be sure to remove this code on release (eg. by putting them in a #if DEBUG section)
And whatever happens, DO NOT try to write to an existing Message box! they are made to pop up and close, not to interact with your code.
This is actually another part of this question.
Error settings breakpoints but only on some lines while debugging
I'm remote debugging a CRM 2011 plugin in vs 2010.
I'n one of my source files I can set breakpoint all throughout the code except in a few places.
When I try to set a breakpoint I get this error
"The following breakpoint cannot be set:" and "The Common Language Runtime was unable to set the breakpoint."
protected override void ExecutePlugin()
{
SetStateResponse response = new SetStateResponse(); // Breakpoint works
// Message switch
switch (_crmMessage) // Breakpoint error
{
case CrmPluginMessageEnum.Create:
Entity pimage = null; // Breakpoint error
if (_context.PostEntityImages.ContainsKey("postcreate")) // Breakpoint works
pimage = _context.PostEntityImages["postcreate"]; // Breakpoint error
break; // Breakpoint error
}
} // Breakpoint error
UPDATE
Also, in the modules window it shows the dll as Optimized: No User Code: Yes Symbol Status: Symbols Loaded
Two possibilities, already kind of referenced by the other answers:
Make sure you are using the Debug build of the assembly instead of
the Release build, because the Release build will remove or optimize
your code.
Make sure you are updating the version each time you
deploy the assemblies in Visual Studio (on project properties tab).
When you increment the version, CRM will be sure to unload the old
assembly version and reload the new one without an IIS reset.
I had this same issue when I had the project open in two instances of Visual Studio. The project which I was not debugging had a lock on the file and notifying me "This file has been modified outside of the source editor." After accepting the changes in my non-debugging solution, I no longer received the error and my breakpoints were hit in my solution I was debugging.
It sounds like there is a lot of possible causes to this error, but this did it for me.
I got this problem when I created a breakpoint using the Ctrl+B shortcut (see image attached), and I entered a name of a function which doesn't exist, so the breakpoint was added but caused an error. then each time I started the project it appeared that error.
Solution:
I deleted the breakpoint from the breakpoints list (see left bottom in image attached), select the breakpoints section, then select the item and click delete.
If you don't see the breakpoints section
You can retrieve it by hitting Ctrl+Alt+B
Further to your update about the DLL being optimised the lines you have indicated where breakpoints don't work will likely be optimised away as your entire switch statement does not do anything other decide whether or not to assign a value to a variable that is never used and does not live beyond the scope of the switch statement. As such the compiler will simply not generate any code for the switch statement as it does not do anything at all or the jit just gets rid of it at run time for the same reason.
I just had a similar experience and the way I worked through it was to put a breakpoint at the spot where the routine was called and then single-stepped into the routine until I saw exactly what it thought it was doing. In my case, there was a return that was preventing all the code in the routine from running, so the optimizer tossed it all out. Sometimes it's the stupid things, right? Anyway, if you start at a level higher in the call stack and step into the routine where the problem is, the reason for the problem might become more obvious.
Another cause of this issue I have just found if you are debugging against CRM is not updating the plugin registration points. Even if you copy the new DLLs to the target machine and attach remotely to that process that is not the DLL CRM will use. CRM will try to take a copy of an old version from its database until you rerun the plugin registrations.
An error which wasted a day and a half for me!
I got this error when start run debugging the project, and I solve it by Clean All Project and Rebuild All Project, after rebuild the error disappear.
Is there something wrong with the .dll file? Shouldn't it just consider the code as closed source since it's all byte code and try NOT to step through it? Is there any way to make this possible?
For example, I have an ASP.net MVC 3 project which is using both Fluent NHibernate and NHibernate. Regardless of which version I use, I can't debug what is happening without having actual access to the source code.
This, I believe poses a problem, for I've installed the necessary binaries to build the project, and therefore SHOULD be able to just debug and get the necessary information available on my variables without stepping through the code itself. If this is not the case (which it isn't, obviously), what can I do about it?
Note: my whole goal here is to see if it's possible to debug my code WITHOUT requiring the source files, as I have the .dll installed, and therefore shouldn't require the source to view the data that variables hold on the stack.
Check to see if Just My Code is enabled in your debug options and settings.
From above link:
Sometimes, while you are debugging, you might want to look at only the code you have written and ignore other code, such as system calls. You can do this with Just My Code debugging. Just My Code hides non-user code so that it does not appear in the debugger windows. When you step, the debugger steps through any non-user code but does not stop in it.