When an exception is thrown in my app, I expect the debugger to stop running and enter debugging mode, but it does not. Instead, I just get a message in the Immediate Window ('A first chance exception ...'), and the program keeps on running like if nothing happened. However, the sub (in which the exception was thrown) is exited, so statements after the exception are not executed. Since this sub makes the initialization of my program, running becomes very unstable.
How can I tell the debugger to stop execution when an exception is thrown?
(I use VB 2010, and did not change any setting of the debugger.)
UPDATE:
Thanks for the quick answer. Unfortunately, I still can't get it the way I'd like.
On the 'Advenced compile options' page I don't have 'Target CPU'. Maybe it's that I have only VB Express?
If I tick the 'Thrown' checkbox in Debug > Exceptions, execution stops even if I have a catch for that exception, and I don't want that.
Until now I used VB 2008 on 32 bit, and everything worked fine, but since I moved to 2010 64 bit I just can't get it right. Any suggestions?
Debug + Exceptions, tick the Thrown checkbox for "Common Language Runtime Exceptions". The debugger will now stop on the first chance notification.
The usual cause is a catch statement in your code, maybe the VB.NET On Error statement. Or a bug in the 64-bit debugger's interaction with Windows Forms. After it breaks, use Debug + Windows + Call stack and check if the form's Load event handler is on the call stack. The bug causes unhandled exceptions to be swallowed without a diagnostic.
To work around that, use Project + Properties, Compile tab, scroll down, Advanced Compile Options. Change the Target CPU setting to "x86". This is the default setting for VS2010 projects btw. You'll now use the 32-bit debugger, it doesn't have this problem. And you can use Edit + Continue.
I know this is an old thread but I hope it may help others..
I was facing a very similar problem at startup of my forms.
I put my code in "shown event", instead of "load event" and it is SOLVED !
I mean I get exceptions as expected, and my codes do not exit silently.
I know they are different events but for me it didn't make any change.
BTW, my env: VB.net Express 2010 on Win7 64 bit
To get the Target CPU option you must have expert settings selected in VS2010 express. Go to Tool|Options and check expert settings.
Related
When I start a debug session, program execution halts at a line that appears to be breakpoint (yellow background color). I must press F5 to continue, and the program proceeds normally.
I call it a phantom breakpoint because no breakpoint appears to be set, and even though executions stops within a loop, I need only press F5 once to proceed.
I tried setting a breakpoint at the phantom location, and removing all breakpoints but to no avail.
The only other similar problems I can find are for Java, and MS-Access where the solution was to de-compile the application.
Although this is very annoying while in development, I was gritting my teeth and baring it until the application was installed on a Citrix server where an error message box is displayed saying that a breakpoint had been encountered.
As an afterthought, I just rebuilt the setup program and after running the application, a critical error was issued. In debug mode, the message was "myapp.exe has triggered a breakpoint:". I cannot explain why it works at all on the Citrix server).
I sure would appreciate any suggestions on how to resolve this issue.
TIA
You are running somebody else's code and that code has an explicit debugger break instruction compiled into the program. You can do so for example by writing Debugger.Break() in a managed program. It could also exist in unmanaged code, the __debugbreak() intrinsic or the DebugBreak() winapi function do this. Could be a simple oversight, it could be that it was intentionally left in the code to warn about a problem.
One way to find the programmer that did this is by using the debugger. Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option. Then Tools + Options, Debugging, General, untick the "Enable Just My Code" option.
Run the program and reproduce the condition. Now use Debug + Windows + Call Stack and look at the very top of the list. Scroll up if necessary. It might well be grayed out to indicate that this is not your code, it won't be. You'll see the name of a DLL there. Call the company or programmer that wrote that DLL and ask for advice.
I always write code like this:
If SomethingIsTrue Then
'DoThis
ElseIf SomeOtherThingIsTrue Then
'DoThat
Else
Debug.Assert (False)'Doh!! I forgot to handle a certain condition
End If
In VB6 this worked great. During testing my app in the IDE, it just stopped in the Debug.Assert(False) line, and I saw where I missed something.
But VB.NET does not stop there but instead gives me a huge messagebox. This seems to be standard behaviour for Debug.Assert.
I have 2 questions, please:
1) How can I make it stop smoothly in that line instead of showing the messagebox?
2) How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
Thank you!
I would write something along this line:
if debugger.isattached=True then
debugger.break
end if
Just wrap it in a shared sub, and you can simply call it in the else statement.
The code is typed without visual studio at hand, so I hope it will work.
How can I make it stop smoothly in that line instead of showing the messagebox?
Just click Retry on the message box that pops up. From MSDN:
Clicking Retry sends you to the code in the debugger if your application is running in a debugger, or offers to open a debugger if it is not.
Clicking Ignore will, well, ignore the message.
How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
I don't mean what you mean with at runtime, since all asserts happen while your code is running, hence at runtime.
If you mean that asserts should be ignored while running your application without a debugger, just make a release build instead of a debug build. The Debug.Assert method works only in debug builds, and the point of debug builds is that they are easy to debug.
If you want nonetheless suppress the message box, see Customizing Assert behavior:
For example, you could override the TraceListener.Fail method to write to an event log instead of displaying the Assertion Failed dialog box.
To customize the output in this way, your program must contain a listener, and you must inherit from TraceListener and override its TraceListener.Fail method.
I was working on a Windows app today, when my errors were no longer being displayed as they usually would. Instead, the debugger just jumps out of the method. The output window makes a note of the exception, but the usual popup trace does not appear.
It works in other projects, and I have put Dim i as Integer = "A" as my first line to try and raise an error, but it just exits the sub on that line.
Any ideas how I get it back?
There is a bug in the interaction between the debugger and the 64-bit version of Windows 7 that strikes in the Load event. An exception is trapped and swallowed by Windows, the debugger never gets a chance to detect that it was unhandled. The only thing you'll see is a "first chance" notification in the Output window. The Load event handler will immediately terminate and your program keeps running as though nothing happened, assuming that it didn't bypass a critical piece of initialization code. This bug has been around for a long time and is well known to Microsoft, apparently it is difficult to fix.
You can work around this bug with Project + Properties, Compile tab, scroll down, Advanced Compile Options button. Change the Target CPU setting to "AnyCPU". Another way to trap it is with Debug + Exceptions, tick the Thrown checkbox on CLR Exceptions. Yet another workaround is to put initialization code in the constructor instead of OnLoad() or the Load event. You only really need Load when you need to know the actual size of the window.
This bug will only strike when you debug. It won't happen on your user's machine.
UPDATE: I expanded a great deal on this mishap in this post.
Under the Debug->Exceptions check that the Common Language Runtime exceptions are checked.
Has your .suo file been deleted by any chance (this is the file that stores your personal state of the solution, your settings, what is expanded / collapsed). You will only really spot this if you suddenly noticed that you had to hit "collapse all" because it had forgotten, it will recreate this when you open the solution, but will do it with default settings.
If so, hit CTRL + ALT + E and re-tick the break on exceptions tick boxes for CLR exceptions.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?