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 :)
Related
I've upgraded my Windows to 10.0.16299 (latest) and my Visual Studio to 15.5.1 (latest). Since then, I am seeing this error message when I clean or build my Xamarin solution containing an Android project:
obj\Debug\android\src\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.java:4:
error: error while writing CustomTabsClient_CustomTabsCallbackImpl:
obj\Debug\android\bin\classes\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.class
(The process cannot access the file because it is being used by
another process)
I figured that the locking process is Visual Studio itself after I tried to run and debug the app.
The issue appears no matter whether I want to run the app on an emulator or a connected real device.
There's lots of advice what to do when a process locks a file including SO such as the famous the process cannot access the file because it is being used by another process. However, all provided answers don't help as Visual Studio itself locks the file and the only workable workaround is to restart Visual Studio - that's not a solution.
What is causing this file to be locked? Any idea? Any advice?
Sometimes it helps to kill the MsBuild.exe. Also, you could find other solutions such as described here: Xamarin Android project cannot build....
Basically, it seems to be a problem with Studio 2017 Version 15.5. It will be fixed with the next versions probably.
Darn it, my suggestions won't fit in the context of a comment, so here goes:
Sounds like the process being debugged, or the emulator hosting the debugged process, itself, has not fully closed down, and is in a hung or semi-hung state. Have you checked the process manager to see if this is the case? You may want to to try adding Environment.Exit() to see if this helps come back to a good state.
Another thing to check is, whether your access levels are the same between the two machines. Check not only the PC, but also at the emulator as well. Check everything, and ensure the access levels/modes are identical.
Finally, try running VS 2017 in administrator mode, and see if the problem persists. It's entirely possible that the level of access that you used to run pre-Windows 10 is different in the Win10 world that you live in, now.
I noticed that an application that I am developing (a game written in C# / XNA) occasionally behaves differently depending on whether it is started from within Microsoft Visual Studio (2010) compared to when it is started outside MSVS (e.g. from Windows Explorer). Specifically, sometimes I get errors (exceptions are drawn) that do not occur within MSVS.
What could be the reason for this difference? Ideally there would be a way to make MSVS check the application as strictly as possible such that I can be sure that all bugs really occur (and can be fixed) during development.
The problem happens in both release and debug mode. The game uses a number of external dlls (nuclex lib, sharp dx) but these libs are all used both from within MSVS and outside. The game entirely runs in a single thread.
Please note that the question is not about a specific error that I need to debug, but it is about general differences that (could) arise from the way an application is started.
There are two main things that cause your program to run differently, when run in Visual Studio.
First of all, the Visual Studio hosting process. I think it's disabled by default. But the toggle for it, if you need it, is in the "Debug" tab of the properties for your application project.
The second, is the fact that the .NET JIT will emit different, more debuggable machine code when a debugger is attached. You can disable this behaviour by unchecking the "Suppress JIT optimization on module load (Managed only)" checkbox in Tools -> Options -> Debugging -> General.
You could try disabling this option and then running your game under the debugger and seeing if the same error occurs. Note, of course, that disabling this will make your program significantly harder to debug - but it does help in a case like this one.
As was mentioned in comments, it is almost unheard of for this kind of problem to be related to the code-generation (although, theoretically, I suppose it's possible). Latent threading bugs caused by changes in performance are far more likely. It could also be a badly behaved native library - although this is also unusual.
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.
I have the source code for a C# project (which wasn't written by me) which I run on one of our servers.
There is a particular part of this program (a menu option) which occasionally fails silently and I can't figure out why from just looking at the source. (The part of the program that fails requires various features that are not on my development machine, so I can't test it on my own machine).
I would like to debug this program and in particular step through the code line by line. Since the server is outside our firewall, remote debugging feature will not work.
Is there any alternative other than installing Visual Studio on the server, ie are there any runtime debuggers that will show the C# source code and allow you to set breakpoints etc?
The project was written in VS 2008 and targets Framework 2.0.
You should be able to use DbgClr for a framework 2.0 app. It is a standalone graphical debugger that comes with the SDK. You will need to ensure that the PDB files, that matches the running build of the application, are available to the debugger.
That being said, if you have any option to punch a hole in the firewall, so you can use remote debugging, that would probably be the easiest way to go.
Of course, it would be best practice to setup your local environment so you can reproduce the bug and debug locally; but I can understand if there are reasons that might make this unfeasible.
Another option is to use WinDbg with the SOS extensions. It's an extremely light weight debugger that doesn't even require the .Net framework to be installed. It leaves much to be desired in the way of UI and has a steep learning curve. But once you get the hang of WinDbg it's an amazingly powerful debugging tool.
I'm finishing up a C# app for work, and looking to make a ClickOnce installer.
Right now, I just want to make sure the installer works and that I am able to run the exe without Visual Studio.
So I set up my project to require Windows Installer and .NET 3.5 SP1, and tell it to download from a vendor (I'll be including the components later, but not for this test). It's just a basic utility that won't need updates, so I disable updates and tell it to use a CD/DVD install method since I just want to run it locally. When I run the resultant setup.exe, I get the installation prompt, and MyApp appears in Add/Remove Programs. But, as soon as the installer finishes it crashes with this message:
[MyApp] has encountered a problem and
needs to close. We are sorry for the
inconvenience.
The same message pops up when you try to run the .exe. No Start Menu folders are created during installation. I tried doing away with creating the setup file altogether so it just generated the .application file, but I still got the same error.
Am I missing something obvious? My app compiles in Release configuration and runs just fine. Is ClickOnce just not supposed to work with regular WinForms applications?
This question:
WPF application crash after ClickOnce publish
Sounds similar to my issue, but I'm using Windows Forms, and thus not getting an XAML exception. It just refuses to run.
A good place to start is to add a handler for the AppDomain.UnhandledException event. This is the event which is raised when an exception occurs inside your code and is not handled by a try/catch block (or is re-thrown and never handled again). .NET's behavior in this condition is to close the application--from it's perspective there is a runaway error.
In this event handler, you should--at a minimum--log the error in a manner that ensures it will be written before the application closes. This could be a very rudementary MessageBox to show the error contents, writing to a text-file, or (preferably) writting to a common logging location.