I have a strange error, which has started suddenly and which is driving me crazy. In my C# application, I am doing some heavy mathematical calculations and for that purpose, I am using CenterSpace's NMath library. Recently, when I started my application from inside Visual Studio 2015 in order to debug it, the application started to crash because of NullReferenceExceptions in NMath.dll, whenever I call an NMath library method (and another library which we have written, as well). In order to isolate the problem, I just run the following very basic matrix multiplication code:
static void Main(string[] args)
{
var mA = new DoubleMatrix(100, 200, 1.5);
var mB = new DoubleMatrix(200, 50, 1.2);
var mC = NMathFunctions.Product(mA, mB);
Console.WriteLine(mC[5, 6]);
Console.WriteLine("Computation finished");
Console.ReadLine();
}
The code crashes in the third line, when I call the "NMathFunctions.Product" method because of a NullReferenceException, with the following exception detail:
It seems that it crashes just in the constructor of the "NMathKernel" object, since an object reference is not properly set.
The most strange thing is, when I run the exactly same program directly from its project folder by using Windows Explorer, not within Visual Studio, the program runs perfectly: The fourth line prints "360.000000001" as expected and the "Console.ReadLine()" is reached!
I am completely clueless about the reason of this NullReferenceException error. It is not a third party dll related problem it seems, since the program only crashes when started from within the Visual Studio. This error completely blocks me from debugging my program with Visual Studio, which is a painful thing, leaves me the only option of debugging it with "Console.WriteLine" calls, from outside of Visual Studio. What can be the reason of this problem? Is something messed up with my Build settings maybe? (Which I have checked and found nothing out of order by the way) Any clues or hints are so much welcome.
In VisualStudio go to Tools -> Options -> Debugging and make sure you have Enable Just My Code option checked.
Go to Debug -> Exceptions and unckeck all Thrown chechboxes. Only leave User-unhandled checkboxes checked. Or just use the Reset all button.
Related
I found myself in this same problem than here, I'm using windows forms in a dll (this is for an Autocad plug-in) and I cannot debug my code because I receive "The application is in break mode. your app has entered a break state, but no code is currently executing that is supported by the selected debug engine". I have tried every recommendation in this list and none worked for me. One odd thing was that I can break in the constructor but the events that use a controller/config object get that page.
Any ideas why this may be happening?
thanks in advance
In my case, I was receiving this same message when calling an MVC API endpoint, and it was also throwing a stack overflow exception. The cause was an object property in an external dll which was written with a backing field. The set accessor of the property was accidentally written to set the property and not the backing field which caused an infinite loop, hence the stack overflow exception. Note the missing underscore in the setter.
private string _Prefix;
public string Prefix
{
get { return _Prefix; }
set { Prefix = value; }
}
Though your issue may not be exactly as mine, something similar is occurring in an external dll.
Restarting visual studio solve this for me.
I've never worked with Autocad but I've made a few plugins for Solidworks and for Creo Parametrics. Here what I usually do when my breakpoint is not working:
Make sure that on build tab of project settings
DEBUG constant is on
Debug info set to full
Optimized code is off
To the code in question add System.Diagnostics.Trace.WriteLine("something unique"); and run it without visual studio attached to make sure your code is actually being called. Check with DebugView utility from sys internals.
Make sure right copy of your dll is loaded :
Run your solution from visual studio as you usually do
Check if you are attached to the right process.
Do actions in Autocad that trigger your code.
Click on Break All button in Debug toolbar in VS
Open Debug->Windows->Modules window and make sure that your dll is present in the list, path is correct and there's pdb file for your dll right next to it.
Add calls to
System.Diagnostics.Debugger.Launch(); and
System.Diagnostics.Debugger.Break(); to your code.
Hope this helps, let me know if you need clarifications for any of the steps.
I have this problem on my Visual Studio 2017 15.8.6.
Maybe my code setting is "Allow unsafe code", but it has the same error code.
The solution is click Tool > Options > Debugging > General > Use Managed Compatibility Mode and activate it.
I found the solution from this forum.
For me, the solution was to install the Oracle.ManagedDataAccess.Core NuGet package only. I had Oracle.ManagedDataAccess installed as well and I needed to uninstall them to fix the Break mode error.
I also had the same issue. After doing some analysis found out that some of the dependent projects were not built properly. Rebuilding all the dependent projects worked for me.
I have an application that occasionally requires you to restart it after changing preferences. I do this by calling:
System.Diagnostics.Process.Start(Application.ResourceAssembly.Location);
That's great for the released version, but it's really annoying when I'm debugging and it relaunches the program outside the debugger whenever I need to change the preferences.
After some research, I've tried attaching to the debugger from code, but the very code I'm trying to run is running in the debugger already, and the application will be killed shortly. So I wrote an external program that can be called after relaunching the application (and freeing up the debugger) that supposedly attaches it to the debugger. Unfortunately this doesn't really do the job either. It appears to get attached to the debugger, but it doesn't actually let me do any debugging. It just craps out with an error if I try to pause execution.
Any ideas?
After more research, I realized all I wanted to do was programmatically hit the Restart button. I found this:
EnvDTE.DTE dte = (EnvDTE.DTE)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.10.0");
dte.ExecuteCommand("Debug.Restart");
Works great!
You may not be able to debug with your code if you are using a Process object and its Attach method from the EnvDTE namespace rather than the Process2 object and its Attach2 method from the EnvDTE80 namespace. The following snippet should work:
foreach (Process2 process in Dte.Debugger.LocalProcesses) {
if (process.ProcessID == processId) {
process.Attach2();
Dte.Debugger.CurrentProcess = process;
}
}
May also be of interest here: the Visual Studio team has released a Visual Studio extension that allows automatically attaching child processes to the current debugger: Introducing the Child Process Debugging Power Tool.
It is available on the Gallery for Visual Studio 2013 and above.
As of today I can no longer debug any c# code using Visual Studio. If I use the debugger, breakpoints can be hit, but as soon as execution has paused the trouble begins. Pressing Step Into, or Continue will normally generate an AccessViolationException saying the memory is corrupt and kill the current request. If I then run a further web request I will instead get an SEHException (occurred in Unknown Module).
It gets even more odd, in that if the AccessViolationException doesn't trigger, the program counter that shows the next statement jumps randomly. Code is then executed in random order! (until it crashes).
If no breakpoints are hit then the app will run in debug mode just fine (even with the debugger attached).
I am confident it's not a code issue. I can actually reproduce the access violations with a new project and the following code:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world");
Console.WriteLine("Access violation"); // This will throw if breakpoint set
}
}
Have deleted VS cache, deleted .suo, cleaned, and tried safe mode. The one possible suspect is that this is on a Windows 10 preview machine, and there was an update last week. I am not really sure where else to go with this to confirm it, or fix it without reimaging the machine.
Changing from Any CPU to just x64 resolved this for me on my "Hello World" test project.
To get working on my original project, which was actually a web project, I had to take a few extra steps.
Update all libraries in the project to x64, not just the web project.
Enable 64 bit IIS express in VS2013 Tools > Options > Projects & Solutions > Web Projects > Use 64 Bit IIS ...
Install Internet Information Services Hostable Web Core through Control Panel (Turn Windows Features On or Off). Before I did this I would get an error when launching 64 bit web projects in the form HttpException (0x80004005): Specified argument was out of the range of valid values. Installing HWC fixed it.
Still none the wiser why any of this is happening, but at least I can debug projects again.
This exception appeared to start out of nowhere and certainly caused me some headache, but I was able to resolve my issue by doing the following:
Go into the properties of the affected Projects
Go to the Debug Tab
Uncheck "Enable native code debugging"
I already created an application with the function that could view the database through that application. When on the Visual Studio 2010 (Haven't released yet), the application that I made run smoothly and no error found. But, when I released it and made a Set-up and install it on my computer and when I run the program and click the view database, it gave the error "Object reference not set to an instance of an object, but when I check back in the Visual Studio 2010, the error didn't appear and run smoothly. Just when I install the application, the error appears.
This is the error that I am getting when run the application through installed program, not through Visual Studio 2010 (Debugging):
When I click "Continue", the program run as it is and run smoothly, I just wondering why this error appears only at the installed program, not in the debugging.
Anyone know how would that happen?
Here is the details:
It's quite likely that something got optimized away by the compiler when building in release mode, which can cause surprises at runtime. Perhaps one of your object is being initialized by a side-effect that the compiler "optimized away".
One easy way to try to get to the bottom of the problem is to wrap the call to the offending method in a try/catch, and when catching the exception, pop it up along with a full stack trace in a message box. What you're interested in is the line number where the null reference exception is actually occurring. Or better yet, write it out to a log file with any additional information you would like to know about at runtime. Then, redeploy your application, reinstall it, and give it another go. Once you figure out which object is not being initialized, then you will want to analyze your code to see why that would happen only in release builds and not in debug builds. You should look to see if you're using some sort of pattern (or anti-pattern) where it could affect other places in your code.
when i start visual studio 2010 c# .. and open my application i got this. it stopped responding and gives me that message in the picture once my application is opened but other application works fine.
then i debug visual studio 2010 .. and i got the exception
Unhandled exception at 0x76a0b9bc in devenv.exe: 0xE0434352: 0xe0434352.
EDIT: i tried to open the .exe file in project folder in debug folder and i got this.
how to fix that ? what should i do ?
thanks in advance.
Visual Studio is vulnerable to certain exceptions that are raised in design mode. Hard to categorize them, it is an immediate crash to the desktop. The exception code says as much, 0xe0434352 is a low-level managed code exception. You'd normally work around it by checking-in an earlier revision of your control and pay extra attention to code that needs to be disabled at design time by checking the DesignMode property. Your screenshot shows as much, seems like the control is actively displaying runtime info while in design mode. Risky.
If you want to debug it then you can by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one (devenv.exe). Debug + Exceptions, tick the Thrown boxes for CLR exceptions and Win32 exceptions. Switch back to the first instance and load your project.
i've figured out what happened .. my form got 3 usercontrol that i made before.. one of those usercontrol has a customized progressBar which is a library .. for some reason that library stopped working .. so i removed it .. then added again from that usercontrol .. then the application worked.