19

I have a project that runs perfect under windows xp.

Now I have tried to run it under Windows 7 and got there a lot of exceptions under Immediate window.

A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.ArgumentException' occurred in LP_Wizard.exe
A first chance exception of type 'System.NullReferenceException' occurred in LP_Wizard.exe
A first chance exception of type 'System.InvalidCastException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.InvalidCastException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe
A first chance exception of type 'System.ArgumentNullException' occurred in Microsoft.VisualBasic.dll
A first chance exception of type 'System.IO.FileNotFoundException' occurred in LP_Wizard.exe

Any idea what wrong with that Microsoft.VisualBasic.dll in windows 7 and how i correct that problem ?

Thanks a lot for help .

BIBD
  • 15,107
  • 25
  • 85
  • 137
Night Walker
  • 20,638
  • 52
  • 151
  • 228

3 Answers3

57

If you want to pinpoint where the exceptions are occurring, you can select the Debug->Exceptions menu item, and in the dialog that appears, check the first checkbox for "Common Language Runtime Exceptions". This will make the debugger break as soon as an exception occurs instead of only breaking on unhandled exceptions.

This is also one reason why it is generally a bad idea to catch generic exceptions unless you are clearly logging the information caught.

Marcus Andrén
  • 965
  • 7
  • 9
  • Thanks a ton. I was generating hundreds of file not founds, and this let me track down and check where it was occurring. – mklauber Feb 04 '11 at 18:56
  • 1
    +1 and catching generic exceptions instead of using flow control slows down your application a lot – nima Feb 28 '12 at 07:55
  • HUGE HELP. It might be an old thread, but I've been banging my head up against a glitch piece of legacy software for the better part of 2 weeks, dealing mainly with folder permissions issues, and this answer actually helped me fix it all in under 5 minutes. GREAT TIP! – Jon Feb 24 '14 at 17:05
  • Many thanks. I had an error in a custom control DLL, but in the host project I set Debug..Exceptions.."Common Language Runtime Exceptions".."Throw" to Ticked (don't worry about the "User-unhandled" setting, or the same settings in the DLL project) and at last I got to see where the actual error was in the DLL project's code (even with the Try..Catch still in operation). Cheers! – AjV Jsy Jun 25 '14 at 11:58
  • Many thanks from me too. I had a generic exception in the entity model, and no way to understand why. Enabling "Commong Language Runtime Exception" has saved my day! – Sandrous Nov 05 '14 at 13:59
44

What is happening is the debugger can "see" exceptions as soon as they are raised (hence the "first chance") before any catch block is hit. Any exception which is not handled by a catch block is considered a "second chance" exception and will break normally.

If these exceptions aren't stopping the running of your application because they are unhandled then you are probably OK. Most of the time the exception is handled by code and this isn't a problem. The output is simply Visual Studio letting you know the exceptions were raised.

See the "Avoiding first chance exception messages when the exception is safely handled" question for some methods to reduce this if there are too many to ignore.

Community
  • 1
  • 1
Adrian Clark
  • 12,449
  • 5
  • 36
  • 42
  • 6
    +1. In addition, if you are triggering a lot of exceptions and catching and ignoring them it might be worth trying to rewrite your code to avoid it as it'll perform much better. e.g use an if(thing != null) before the call instead of a catch(NullPointerException) afterwards. – Paolo Jan 07 '10 at 13:23
  • 1
    Definitely, Paolo. Exceptions should be exceptional. Of course if the exceptions are happening in Microsoft.VisualBasic.dll there are probably not too many things you can do, unfortunately. :) – Adrian Clark Jan 07 '10 at 13:26
  • Even if the exception is happening in Microsoft.VisualBasic.dll, it's most likely that it's being caused by an error in your own code, rather than a bug in the Microsoft code. – MarkJ Jan 07 '10 at 13:31
  • But How i can see where they come from in the code ? I just cant see the place it happens – Night Walker Jan 07 '10 at 13:37
  • 1
    Change the debugger setting so that it stops on first chance exceptions. Look back at the call stack to the last part of your code before it goes into the Microsoft DLL. Figure out what is wrong with your call into the Microsoft code. If everything is fine then just turn off the warnings, as in the linked question. – MarkJ Jan 07 '10 at 15:08
1

Are your in the debugger? Are these exceptions your program is handling? If so you need to find a setting that tells VB to supress warning you of handled exceptions. Maybey this was set when installed on XP but not when you installed on W7. See if this helps:

http://www.helixoft.com/blog/archives/24

fupsduck
  • 3,129
  • 1
  • 19
  • 18