I get an AccessViolationException while debugging an application, but don't get this exception while running this application as release without attached debugger. The application is a very thread-intensive (up to 10000+) network-server (tcp/socket).
The application has run the whole last night compiled as release, without attached debugger and under heavy load. In fact the application didn't ever crash without attached debugger.
When I run the application compiled as Release with attached debugger I get an AccessViolationException-Exception (sometimes). This exception just gets thrown without any hint where this exception occurs. When I press Ok in the appearing exception-box in Visual Studio and then navigate to the thread where the exception occurred. I can't see any code or stacktrace there:
(Thread #186840 has no memory-location.)
This is my (reduced) test-program: example-code. (You should have enough ram and cpu and you should compile it as release. First start the server-application, then generate load with the client-application.)
Now my question(s): How can I debug such errors? Does anyone know about a bug in .NET while debugging such thread-intensive programs?
I'm using Visual Studio 2013 Update 4. The project is a Any Cpu; .NET 4.0 C# project. I have installed all windows update patches and was running this on Windows 8.1. The JIT compiler compiled the code to x64.
Related
My computer is on Windows 10 build 16299, which is the minimum required version for the UWP restart functionality in CoreApplication.RequestRestartAsync(...). However, after I make the call to restart, with arguments of string.Empty, the App does close and a few seconds later an Exception is thrown from System.Private.CoreLib.dll:
Exception occurred: System.Exception: Exception from HRESULT: 0x80040900
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
I am able to get this information from a Try/Catch block and am running the app from Visual Studio 2017 in debug mode. Before I attempted to catch it, a dialog would appear indicating to debug in another instance of Visual Studio. When the other instance loaded, this was not allowed because it said a debugger was already attached.
Additionally, I tried to catch it by enabling "Common Language Runtime Exceptions", but it did not catch this Exception.
Why is this happening? When I use run this on another Windows 10 machine, the restart works fine. Can I debug or get more information about the Exception in System.Private.CoreLib?
This error will not happen to affect your app's real experience when you install your app and run it without connecting the Visual studio to debug. Visual Studio prevents Windows from suspending an app that is attached to the debugger. This is to allow the user to view the Visual Studio debug UI while the app is running. When you debug this code with Visual Studio, you can see the App status is still Running in your device Task Manager => Details tab after you called this method, so the app can not restart, since prior to Windows 10, version 1803, only one instance of a UWP app could be running at a time. More details about multi-instance UWP, please see Create a multi-instance Universal Windows App.
But in my test on the device OS version 1803 OS build 17134 and Visual studio version 15.7, it will disconnect the Visual Studio debugger automatically after you call CoreApplication.RequestRestartAsync(string.Empty) code.
I'm a windows kernel-mode (Driver) developer and for this purpose(Develop drivers and debug that ) i enabled kernel debugger on my system.
But when i want to debug a managed-code (A C# project) in my system, using Visual Studio debugger i receive the following error message:
Debugging isn't possible because a kernel debugger is enabled on the system
In this case what should i do ?? (I don't want to disable kernel debugging or use any other debugger instead of VS debugger).
Any idea ?
According to Microsoft this is a known issue. If you upgrade your project to target .NET 4.0 or 4.5. it should work without disabling the kernel debugger.
I develop C# applications using VS 2010 Ultimate.
Usually, those applications run for long time, without user interaction and, of course, they usually have bugs inside.
Unfortunately, often the application crashes randomly and you just can't reproduce the error. Also sometimes I only have the message "The application has stopped working" with no more informations.
I can install Visual Studio on the machine of the customer, but I can't let him run VS and compile/start the source code in debug mode! What I need is to start VS after the application was started and crashed. It seems to be possible to do this, in fact when an exception happens at runtime, Windows ask you "do you want to debug with VS?", but if I answer YES, then VS starts but simply I can't see the source code (it is on the pc as well), thus I can't inspect the row of code that is causing the exception. VS just tells me "source code not available". Actually, I can't imagine how Windows could start VS and know where the source code of the crashed application is!
Does anyone knows how does this debugging scenario is intended to work, and how to configure it??
Thanks a lot,
Simone
Windbg debugging tool solves the purpose.
Take dump of the process state and start analyzing with windbg. It gives you the exception information
To debug from an already-running Visual Studio instance, select the "Debug" menu item, then "Attach to Process..."
Next, select the executable from the list, press "Attach" (or double-click), and you are now debugging the application. When you select "Yes" and Windows says that source code is not available, this most likely means that the PDB wasn't able to be loaded, so make sure that you have loaded the symbols for the module by examining it in the "Modules" window pane.
If you want to catch errors while running compiled program, you should use some sort of logging mechanism. These days you don't have to write it on your own, there's a great opensource logging engine designed for .NET applications, it's called NLog. It's capable of saving logs into files, emails, console or database, pretty much all you can want :).
Hope this helps :)
I am working on a WPF application.
Which is running fine with "Any CPU" as Active solution platform, but when it is changed to "x86" application starts but stoping without showing up any form or error message.
Application neither throws any exception nor logging any error in event log.
I am running this application on .NET 4.0 framework and Windows 7 64 bit OS.
appreciate your help to solve this issue.
Thanks,
maxk
First off, it's strange that you don't get any error messages. Not even when you launch the built application without debugger?
The best answer anyone can give based on the information provided, is to do some trial and error debugging:
1) Create a new empty project, set it to x86, see if it runs. If not, there is some serious problems with your machine setup, you'll probably have to reinstall.
2) In your own project, if you have any external references start removing them one by one and see if your app starts to run. Maybe a referenced dll is causing havoc in 32-bit mode.
3) Start commenting out blocks of code to see if your app starts to run then. I've found out that having errors in Window_Loaded methods (especially while debugging) can cause problems - exceptions not being handled, application crashing etc.
4) Could be that you have a bad Visual Studio plugin (I assume you are using VS and problems are occuring on your development machine). Try running the app without debugging...
5) Create a virtual machine and try your app in there, if it works there, then your machine is somehow "corrupted"..
PS! Just for your information, because you are running a 64-bit OS, then the Any CPU setting causes your app to be 64-bit. Forcing it to be 32-bit can cause problems if you are using badly written native dlls (although it's usually the other way round - problems occuring when going to 64-bit from 32-bit).
I have a program that I built that reads and writes files. I built it in Release mode, then tried to run the exe on Win7. At first, with troubleshooting on, Windows simply told me the application closed and it was looking for a solution. After a few seconds, the dialog would disappear and show nothing more.
So with some significant effort I got the debugger attached to the process, but it was only showing me disassembly, which tells me that the error taking place wasn't in my application code, but in the framework somewhere.
The strange thing is that when I let the debugger attach, then press "stop" in VS, and exit the debugger, the program actually runs at that point!
So now I'm stumped. I have an application that builds, that seems to be having a permission error when I run it, but if I let the debugger attach then close it, it runs, and there's no Exception to really look at.
How I troubleshoot this issue?
Edit: Responding to Merlyn:
It's a custom app written from scratch in c#. The only dependency it has outside of core .NET namespaces is the Ionic.Zip DLL.
Visual Studio 2008 (Writing in C# 3.5)
Windows 7 - Home Premium, v6.1 build 7600
CPU - x64 quad core
CPU are you compiling under: Any CPU
I haven't tried it on another machine or a different version of VS.
Edit: I was able to try the compiled version on another win7 computer, and it worked without issue, so it looks like a security (?) issue on my computer only.
Try it in the debugger with Just My Code disabled and Native Code enabled, then check the call stack.
Also, what happens if you run it directly in Visual Studio?
Uncheck Enable Visual Studio Hosting Process in Project Properties and see whether it still works in VS.
I'd suggest sending the issue to Microsoft support. Especially with the data given here, you will have an easy time convincing them it's their problem. You might need an MSDN subscription for that.