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
Related
Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
I run my program in DebugMode and then quit it by closing the main form.
In the output window I can see the following message:
Uninit : Still Alive 1The program "[1432] App1.exe: Managed (v4.0.30319)" was ended with code 0 (0x0).
I wonder what the "Uninit : Still Alive 1" means.
Does anybody know???
I am always really scared of something unexpected occuring at some point of time, and the message "Still Alive" does not really sound promising to me.
Thank you for the help!
It is a diagnostic message that was generated with OutputDebugString(). It is present in one of the DLLs that you have a dependency on. The exact meaning requires interpretation, but "Uninit" is short for "Uninitialize", the kind of thing that happens when a DLL gets unloaded. And "Still Alive 1" would probably mean that the programmer of the DLL is miffed about you not properly shutting down his component before you jerked the floor mat.
The message is missing a line-break ("\n"), a pretty standard mistake that programmers make when they use OutputDebugString.
Two basic ways to find the DLL that does this. First one is to turn on unmanaged debugging with Project + Properties, Debug tab, tick the "Enable native code debugging" checkbox. The DLL unload notification should be close to the diagnostic message.
More reliable is using SysInternals' Process Explorer. Select your process and press Ctrl+D to list the DLLs it has loaded. Given the quality of the message, you can probably skip the ones that have a Microsoft copyright. Right-click the DLLs one-by-one and look at the "Strings" tab to see the strings inside the DLL. Once you find it, you should know who owns that code from the DLL name. Ask them how to shut down properly.
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.
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.
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?