4

I am writting a C# application using Windows Forms and Visual Studio 2010 Professional. The machine is using Windows 7 Enterprise and it is 32bit. Although i think it is not relevant, i am working on a virtual machine (using Remote Desktop Connection).

The problem is that when an exception is generated in the Load method of a form, both VS and the program freeze/hang (actually, i can't even show a folder or go to desktop) and it just stops when I kill the process of the application i was debugging.

This happens in debug mode (F5) and not in non-debug mode (ctrl+F5). I searched a lot about this and this is a known issue for x64 machines. This is why I find it really weird that it is happening, exactly as a lot of people report for 64bit computers, but in a x86 architecture.

By now i am getting of by running the code i want to debug in another function besides the Load one, but in the future it might be problematic.

Thanks in advance for any kind of input.

------------------------------ EDIT ---------------------------------------------

I just noticed that I can't even debug using breakpoints in the Load method (instead of showing the break point, it just hangs...). Nobody had this issue before? :/

viper
  • 974
  • 6
  • 13
  • 1
    Everyone is going to say this: let us see some code. – gunr2171 Mar 27 '13 at 18:40
  • I'm not sure whether code is really relevant here, could be a system setup issue, too. **1.** It would be interesting to know if this happens with *any* and all exceptions (i.e. if a simple program `static void Main() { throw new NotImplementedException(); } ` exhibits the same behaviour, or only the OP's very specific exception/program. **2.** Can you by chance set up a x64 VM on x86 hardware...? – stakx - no longer contributing Mar 27 '13 at 18:45
  • @stakx, it seems that this question could be either a code issue (infinite loop, bad code, etc) or an environment issue. It is really hard to tell without evidence for one or the other. – gunr2171 Mar 27 '13 at 18:49
  • @gunr2171: *If* the OP's assessment is correct and the problem *is* caused by an exception, then we're not dealing with an infinite loop. All you are likely to see in the code is that it throws an exception in some way. But I don't see how "bad code" could possibly affect Visual Studio (another process!), since the OS should isolate processes. -- I would much rather know a little more about the VM setup: free HDD space, memory, ... before and after the process crashes; that sort of thing. Perhaps *that* would give further hints where the problem could be. – stakx - no longer contributing Mar 27 '13 at 18:59
  • @gunr2171: ... but of course seeing the code won't hurt. I just suspect that knowing more about the environment might be *more* important. – stakx - no longer contributing Mar 27 '13 at 19:00
  • @stakx, I agree, I was just throwing out suggestions. But this seems like an extremely isolated case. And seeing the lack of any supporting information, I would vote to close this. – gunr2171 Mar 27 '13 at 19:01
  • I would [attach a separate VS instance to it](http://stackoverflow.com/a/39791/299327) and see what that gives you. – Ryan Gates Mar 27 '13 at 19:31
  • @gunr2171 There isn't the need for code, I was very clear in my explanation. You are just assuming i was not :) When I said "when an exception" I meant ANY exception. A simple throw new NotImplementedException();makes both the app and VS hang, as do any other exceptions(null pointer, enums that can't be resolved). The problem isn't on the code. As i've said, it's on an exception, not in dead-locks, infinte loops etc. My explanation is clear :) – viper Mar 28 '13 at 10:24
  • @Ryan Gates thank you for your input, but I would appreciate a bit more detail. First, I don't see the option "devenv" in the instruction "Debug -> Attach to Process" and pick "devenv". Second I don't really understand the second sentence, and I am not debbuging the Visual Designer, but yes the code inside the load (which is related to class' instantiation and DB acesses). Do you think this alternative is still uselful? – viper Mar 28 '13 at 10:34

2 Answers2

2

Well guys, found out what was the problem.

The problem consisted in the fact that I had the property 'TopMost' of my form set to true. Oddly, when an exception happened, I couldn't even minimize my application, what simulated an hang up situation, while what was happening was only that my form was waiting for an answer from VS (that was showing the exception, but it was seeable). As it was in the 'Load' method, the form stayed frozen, leaving me no alternative than to kill it.

Thanks for your suggestions, and I guess that finally I was wrong, it really was on the code :) (Although I still think that something weird was happening due to the fact that I couldn't even minimize my app).

(You can close this thread or whatever you do when something is solved for sure :P )

viper
  • 974
  • 6
  • 13
  • some one better pick up the phone. because i CALLED IT! – gunr2171 Mar 28 '13 at 15:57
  • @gunr2171 Heheh not exactly, but in a way you were right :). I guess that, even if I had posted the code, nobody would ever find the TopMost property, moreover because it was in the auto-generated code. In any case, is this behaviour normal? Shouldn't I be able to, at least, minimize my app? – viper Mar 28 '13 at 16:28
  • Yes, you are right, while my initial thought was "correct", you are right in saying it would be very hard to pin-point where the error was comming from. As for expected behavior, I'm not sure. Visual studio hosts an exe, which in-turn runs your code on a different thread. Past that I have not experimented. – gunr2171 Mar 28 '13 at 16:32
  • Alright, so after a quick experiment it seems like when you set a form as "TopMost" then the window is truly top most, even during a breakpoint. This must be because you register the form (in the background) with Windows, and the form is still technically active (although paused). So yes, by design. – gunr2171 Mar 28 '13 at 16:41
  • @gunr2171 thanks for testing it too. I guess this answer (mine) should then be marked as best, considering that a lot of other people can find this problem and take a while to figure out that it comes from the 'TopMost' property, as I did. What was driving me nuts was the fact that this mimics to almost perfection the behaviour of exceptions during the 'Load' method in 64bit machines. As mine is 32bit.. I was like how is this even possible to just happen to me!?! Glad it is solved, thank you all! – viper Mar 28 '13 at 17:43
  • This is just one more reason to stay away from Modal and TopMost windows. – Ryan Gates Apr 01 '13 at 14:56
0

Install the Microsoft Debugging Tools for Windows: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Attach this tool to VS and produce your error, the tool creates a dump/snapshot of the program at the exception time, you can get all the information about the health of the application using this tool, it is not easy to use but will help you alot.

Siraf
  • 1,133
  • 9
  • 24