C# Programming :: .NET 2.0 app crashes without normal verbose dialog??


	.NET 2.0 app crashes without normal verbose dialog?? I've got a .NET 2.0 app that works quite well on all of my test boxes. However, at the client's site, it crashes with 'has encounted a problem' basic dialog. No useful info. I've yet to see a .NET app crash like this, without the verbose dialog that will tell me the line # of the problem (the app was compiled in debug mode). What steps can I take to track this down? The app uses some .NET dlls for remoting, and a COM objects. But, it crashes before even loading a window. I'm looking into adding some ThreadExceptionEventHandler and UnhandledExceptionEventHandler's to the app. But, I'd like to try to resolve this without throwing too many different versions at my client, who is not very computer savy and is probably as frustrated as I am. I've never encountered this before, in all the years I've worked with .NET. -- Thanks in advance, Les Caudle On Jun 5, 10:59 pm, Les Caudle <DotNetWann@newsgroup.nospam> wrote: - Hide quoted text - > I've got a .NET 2.0 app that works quite well on all of my test boxes. > However, at the client's site, it crashes with > 'has encounted a problem' basic dialog. No useful info. > I've yet to see a .NET app crash like this, without the verbose dialog that will > tell me the line # of the problem (the app was compiled in debug mode). > What steps can I take to track this down? > The app uses some .NET dlls for remoting, and a COM objects. > But, it crashes before even loading a window. > I'm looking into adding some ThreadExceptionEventHandler and > UnhandledExceptionEventHandler's to the app. > But, I'd like to try to resolve this without throwing too many different > versions at my client, who is not very computer savy and is probably as > frustrated as I am. > I've never encountered this before, in all the years I've worked with .NET. > -- > Thanks in advance, Les Caudle May be a problem with .Net framework installation. Uninstall framework and VS(if installed) completely and reboot. Re-install everything.and try. I don't see any other way. -----------------------------------------------Reply----------------------------------------------- I had her 'repair' .NET 2.0. We tested with a simple .NET app that opens a window, so .NET seems to be installed ok. The only problem is with my more complex app, which crashes. Guess I'll modify to see about any untrapped exceptions. Thanks, Les Caudle - Hide quoted text - On Tue, 05 Jun 2007 11:10:01 -0700, Aneesh Pulukkul <anees@gmail.com> wrote: >On Jun 5, 10:59 pm, Les Caudle <DotNetWann@newsgroup.nospam> wrote: >> I've got a .NET 2.0 app that works quite well on all of my test boxes. >> However, at the client's site, it crashes with >> 'has encounted a problem' basic dialog. No useful info. >> I've yet to see a .NET app crash like this, without the verbose dialog that will >> tell me the line # of the problem (the app was compiled in debug mode). >> What steps can I take to track this down? >> The app uses some .NET dlls for remoting, and a COM objects. >> But, it crashes before even loading a window. >> I'm looking into adding some ThreadExceptionEventHandler and >> UnhandledExceptionEventHandler's to the app. >> But, I'd like to try to resolve this without throwing too many different >> versions at my client, who is not very computer savy and is probably as >> frustrated as I am. >> I've never encountered this before, in all the years I've worked with .NET. >> -- >> Thanks in advance, Les Caudle >May be a problem with .Net framework installation. Uninstall framework >and VS(if installed) completely and reboot. Re-install everything.and >try. I don't see any other way. -- Thanks in advance, Les Caudle -----------------------------------------------Reply----------------------------------------------- It seems that is the security issue or one of your app files missing. -- cheers, RL "Les Caudle" <DotNetWann@newsgroup.nospam> wrote in message news:9ebb631cggoe06n1su6vidlkq0p4ni4tne@4ax.com... - Hide quoted text - >I had her 'repair' .NET 2.0. > We tested with a simple .NET app that opens a window, so .NET seems to be > installed ok. > The only problem is with my more complex app, which crashes. > Guess I'll modify to see about any untrapped exceptions. > Thanks, Les Caudle > On Tue, 05 Jun 2007 11:10:01 -0700, Aneesh Pulukkul <anees@gmail.com> > wrote: >>On Jun 5, 10:59 pm, Les Caudle <DotNetWann@newsgroup.nospam> wrote: >>> I've got a .NET 2.0 app that works quite well on all of my test boxes. >>> However, at the client's site, it crashes with >>> 'has encounted a problem' basic dialog. No useful info. >>> I've yet to see a .NET app crash like this, without the verbose dialog >>> that will >>> tell me the line # of the problem (the app was compiled in debug mode). >>> What steps can I take to track this down? >>> The app uses some .NET dlls for remoting, and a COM objects. >>> But, it crashes before even loading a window. >>> I'm looking into adding some ThreadExceptionEventHandler and >>> UnhandledExceptionEventHandler's to the app. >>> But, I'd like to try to resolve this without throwing too many different >>> versions at my client, who is not very computer savy and is probably as >>> frustrated as I am. >>> I've never encountered this before, in all the years I've worked with >>> .NET. >>> -- >>> Thanks in advance, Les Caudle >>May be a problem with .Net framework installation. Uninstall framework >>and VS(if installed) completely and reboot. Re-install everything.and >>try. I don't see any other way. > -- > Thanks in advance, Les Caudle User installed it on a network share, which caused the problem, a security violation. Still usure why it didn't fail with the normal dialog - as it is very hard to guess at this remotely with so little information. Regards, Les Caudle - Hide quoted text - On Tue, 5 Jun 2007 16:51:43 -0600, "Egghead" <robertlo@NO_SHAW.CA> wrote: >It seems that is the security issue or one of your app files missing. Hi Les, Can you tell me the type of your .Net application, is it console, Winform? Normally, the verbose error dialog will only show in the .Net Winform application. .Net console application will not show verbose error dialog. Please refer to the link below to understand the default behavior of unhandled error in different type of .Net applications: http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx However, in .Net Winform, if the .Net unhandled exception is generated before Application.Run() method is called, the verbose error dialog will not show, the behavior will be same as console application, which pops a 'has encounted a problem' dialog in a clear machine. Also, if the exception is generated in a non-GUI worker thread, it will behave like console application. You may register AppDomain.UnhandledException event yourself to be notified the error in the current AppDomain. In this event, you may use Environment.StackTrace to examine the stace trace of this unhandled exception. This will help you to examine the cause of this problem. If you want to perform an intensive debugging for this problem in the client machine, I would recommend you to installed a light-weight windbg on the client machine to catch this unhandled exception, see my blog entry below for the configuration and details: "How to debug application crash/hang in production environment?" http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-applicat... sh-hang-in-production-environment.aspx Additionally, based on your last reply, it seems that your problem is caused by .Net Code Access Security check. You may run "caspol.exe -s off" in "Visual Studio 2005 Command Prompt" to turn off the .Net2.0 CAS check temparily. If this error goes away, it means that it is caused by CAS check. If you have determined that the problem is caused by CAS, you may follow the following steps to evaluate the permission set and code group of your application assembly: You can open ".Net Configuration 2.0" tool from "Administrative tools" in Control Panel. Click "Runtime Security Policy" node the left panel. Then click "Evaluate Assembly" link in the right panel. In the popup dialog, input your assembly path, and click next to evaluate your assembly permission set. Normally, it should be Unrestricted. Please paste any details here for further analysis, thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp... ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. -----------------------------------------------Reply----------------------------------------------- Jeffrey - it is a windows form app. It uses several .NET remoting DLLS, and it might be possible that they are somehow called (as they are set up in the config file) and cause the behavior where there is no useful dialog. Thank you for the detailed response. I think I have a handle on it now. I was just stressed a bit as the 1st thing my client saw when trying to run the software was this crash, and I had no idea she'd copied the code to a network share. Regards, Les Caudle On Wed, 06 Jun 2007 03:29:58 GMT, j@online.microsoft.com ("Jeffrey - Hide quoted text - Tan[MSFT]") wrote: >Hi Les, >Can you tell me the type of your .Net application, is it console, Winform? >Normally, the verbose error dialog will only show in the .Net Winform >application. .Net console application will not show verbose error dialog. >Please refer to the link below to understand the default behavior of >unhandled error in different type of .Net applications: >http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx >However, in .Net Winform, if the .Net unhandled exception is generated >before Application.Run() method is called, the verbose error dialog will >not show, the behavior will be same as console application, which pops a >'has encounted a problem' dialog in a clear machine. Also, if the exception >is generated in a non-GUI worker thread, it will behave like console >application. >You may register AppDomain.UnhandledException event yourself to be notified >the error in the current AppDomain. In this event, you may use >Environment.StackTrace to examine the stace trace of this unhandled >exception. This will help you to examine the cause of this problem. >If you want to perform an intensive debugging for this problem in the >client machine, I would recommend you to installed a light-weight windbg on >the client machine to catch this unhandled exception, see my blog entry >below for the configuration and details: >"How to debug application crash/hang in production environment?" >http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-applicat... >sh-hang-in-production-environment.aspx >Additionally, based on your last reply, it seems that your problem is >caused by .Net Code Access Security check. You may run "caspol.exe -s off" >in "Visual Studio 2005 Command Prompt" to turn off the .Net2.0 CAS check >temparily. If this error goes away, it means that it is caused by CAS >check. If you have determined that the problem is caused by CAS, you may >follow the following steps to evaluate the permission set and code group of >your application assembly: >You can open ".Net Configuration 2.0" tool from "Administrative tools" in >Control Panel. Click "Runtime Security Policy" node the left panel. Then >click "Evaluate Assembly" link in the right panel. >In the popup dialog, input your assembly path, and click next to evaluate >your assembly permission set. Normally, it should be Unrestricted. >Please paste any details here for further analysis, thanks. >Best regards, >Jeffrey Tan >Microsoft Online Community Support >================================================== >Get notification to my posts through email? Please refer to >http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp... >ications. >Note: The MSDN Managed Newsgroup support offering is for non-urgent issues >where an initial response from the community or a Microsoft Support >Engineer within 1 business day is acceptable. Please note that each follow >up response may take approximately 2 business days as the support >professional working with you may need further investigation to reach the >most efficient resolution. The offering is not appropriate for situations >that require urgent, real-time or phone-based interactions or complex >project analysis and dump analysis issues. Issues of this nature are best >handled working with a dedicated Microsoft Support Engineer by contacting >Microsoft Customer Support Services (CSS) at >http://msdn.microsoft.com/subscriptions/support/default.aspx. >================================================== >This posting is provided "AS IS" with no warranties, and confers no rights. -- Thanks in advance, Les Caudle -----------------------------------------------Reply----------------------------------------------- Ok, if you need further help, please feel free to feedback, thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp... ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. -----------------------------------------------Reply----------------------------------------------- I came across a similar 'problem'. It turned out to be that in the initial load of the form there was a call to a config file that I had not included in the build, once this was placed in the correct location the application loaded correctly. I seem to recall it threw an unhandled error. From this point on I now include full try{} catch{} blocks whenever. Also use multiple catch{} blocks to enable better debugging information. Simon