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.
Related
I have Windows 7/64 Pro box with Visual Studio 2012 Ultimate, revised to Update 4, with a problem.
Over the last week, I've started experiencing a problem that was originally tolerable, but now has grown worse to a matter of unusability, and I'm in need of some (any?) suggestions. It may turn out this is more appropriate over as a Microsoft issue moreso than a purely programming issue, but I thought perhaps someone might have experienced the issue, hence I'm taking a shot here.
The problem: The VS2012 IDE, moments after starting, seizes with no solution or project loaded, going into "Not Responding" mode, never to return. Worse, however, is that when this occurs, it blocks the OS from starting any 32-bit processes, and 64-bit processes aren't exactly responsive.
This had occurred only once or twice in the last week, and thus I assumed it was an odd/one-off situation and didn't think it was a chronic problem. Today became chronic. Whereas over the last few days this symptom was unusual, today it prevented me from working in VS2012 all day. The VS2012 IDE would be responsive for a brief time, then seize up.
Doing a bit of research on the nature of the issue, and observing it didn't occur until I started VS2012, I began to realize it must be associated with the native VS executable or the ancillary devenv.exe that starts along with it. The real culprit, however, was the Microsoft.VisualStudio.Web.Host.exe executable that provides the web version of the VS hosting environment that was causing the problem.
When the VS2012 IDE would seize, killing the Web.Host.exe process would immediately free the IDE for a time, and allow any "queued" 32-bit apps to start. However, the symptom would return as soon as the web hosting process restarted.
I have updated VS2012 to Update 4, and performed a repair installation of VS2012, and nothing has changed. There are no errors in the event logs that would indicate hardware issues (such as a hard drive failure) or any other lower-level/organic OS issues. There's really nothing to configure (that I know of) on the web host process side, so short of a complete reinstall of VS2012, I'm not sure what else to try.
I saw a fleeting resemblance to this error in a Microsoft Connect forum, but the symptoms were not, in fact, identical, and the prescribed fix (VS2012 up to Update 4) was to no avail.
Edit: Minor bit of additional information - the only unusual element that might prove an "x-factor" in this situation is the recent switch to TFS - within the last week - frighteningly coincident with the onset of the problem. But thinking the SCC provider would be less interested in the content than supporting things like Intellisense, debugging, and the like, I had a tough time convincing myself it would be a player. At this point, however, who knows.
Any suggestions appreciated.
Regret that I can only offer a general solution for this - after updating to Update 4, I then performed a Repair Install of Visual Studio 2012, and since that time, this lockup problem has not recurred. I can't say if a particular library was updated or reinstalled, or if some configuration setting was changed, but either way (so far) VS 2012 is happy and I'm working again. Will update with more information if I find it.
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.
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.