|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Unhandled exception vs handled (security issue)network drive. I understand what the exception is and how to fix it by granting the application permission on each client. This is a related but different question. app1 generates the following dialog: "app1.exe - CLR Debugging Services Application has generated an exception that could not be handled. Process id=, Thread id=. Ok to end, Cancel to debug" Totally useless. I recently wrote another app (app2) which needed to be granted permission to run across a network, but forgot to grant it. Having forgotten, I get the following dialog: "Microsoft .NET Framework The application attempted to perform an operation not allowed by the security policy. The operation required the SecurityException. To grant this application..." (what follows is a great deal more useful information) A very informative and useful dialog. My question is: Why am I getting two different dialogs for the same thing? I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). In the case of app1, the only way to discover what the exception class is, is to launch the debugger. It is System.Security.SecurityException. In the case of app2, the dialog itself contains all the information you need, including the class of the exception. It is System.Security.Permissions.RegistryPermission. There IS no way to trap these exceptions and display to the user something useful (which I would like to do for app1) because they occur outside of Main. What's up with this? The very last resort to handle an "unhandled" exception is in your AppDomain.
Implement an eventsink for this event: AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); Here you could potentially handle any "unhandled" exceptions, potentially presenting some logging mechanism for this. -- Show quoteHide quotergds. /Claus Konrad MCSD.NET (C#) "Tergiver" wrote: > An exception occurs when attempting to run the application (app1) from a > network drive. I understand what the exception is and how to fix it by > granting the application permission on each client. This is a related but > different question. > > app1 generates the following dialog: > "app1.exe - CLR Debugging Services > Application has generated an exception that could not be handled. > Process id=, Thread id=. > Ok to end, Cancel to debug" > > Totally useless. > > I recently wrote another app (app2) which needed to be granted permission to > run across a network, but forgot to grant it. Having forgotten, I get the > following dialog: > > "Microsoft .NET Framework > The application attempted to perform an operation not allowed by the > security policy. The operation required the SecurityException. To grant this > application..." (what follows is a great deal more useful information) > > A very informative and useful dialog. > > My question is: > > Why am I getting two different dialogs for the same thing? > I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). > > In the case of app1, the only way to discover what the exception class is, > is to launch the debugger. It is System.Security.SecurityException. > In the case of app2, the dialog itself contains all the information you > need, including the class of the exception. It is > System.Security.Permissions.RegistryPermission. > > There IS no way to trap these exceptions and display to the user something > useful (which I would like to do for app1) because they occur outside of Main. > > What's up with this? > Where am I supposed to put this line of code?
Obviously Main is not correct as Main isn't called before the exception occurs. I tried a static constructor for the object that contains Main, but again the exception occurs earlier. Show quoteHide quote "Claus Konrad [MCSD]" wrote: > The very last resort to handle an "unhandled" exception is in your AppDomain. > Implement an eventsink for this event: > > AppDomain.CurrentDomain.UnhandledException += new > UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); > > Here you could potentially handle any "unhandled" exceptions, potentially > presenting some logging mechanism for this. > > -- > rgds. > /Claus Konrad > MCSD.NET (C#) > > > "Tergiver" wrote: > > > An exception occurs when attempting to run the application (app1) from a > > network drive. I understand what the exception is and how to fix it by > > granting the application permission on each client. This is a related but > > different question. > > > > app1 generates the following dialog: > > "app1.exe - CLR Debugging Services > > Application has generated an exception that could not be handled. > > Process id=, Thread id=. > > Ok to end, Cancel to debug" > > > > Totally useless. > > > > I recently wrote another app (app2) which needed to be granted permission to > > run across a network, but forgot to grant it. Having forgotten, I get the > > following dialog: > > > > "Microsoft .NET Framework > > The application attempted to perform an operation not allowed by the > > security policy. The operation required the SecurityException. To grant this > > application..." (what follows is a great deal more useful information) > > > > A very informative and useful dialog. > > > > My question is: > > > > Why am I getting two different dialogs for the same thing? > > I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). > > > > In the case of app1, the only way to discover what the exception class is, > > is to launch the debugger. It is System.Security.SecurityException. > > In the case of app2, the dialog itself contains all the information you > > need, including the class of the exception. It is > > System.Security.Permissions.RegistryPermission. > > > > There IS no way to trap these exceptions and display to the user something > > useful (which I would like to do for app1) because they occur outside of Main. > > > > What's up with this? > > And one other thing:
The help documentation for AppDomain.UnhandledException says you need SecurityPermission to add a handler to the event. Therefore, it's a circular problem. Adding this line would cause the unhandled exception which would occur outside your ability to trap it which would cause the unhandled exception... Show quoteHide quote "Claus Konrad [MCSD]" wrote: > The very last resort to handle an "unhandled" exception is in your AppDomain. > Implement an eventsink for this event: > > AppDomain.CurrentDomain.UnhandledException += new > UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); > > Here you could potentially handle any "unhandled" exceptions, potentially > presenting some logging mechanism for this. > > -- > rgds. > /Claus Konrad > MCSD.NET (C#) > > > "Tergiver" wrote: > > > An exception occurs when attempting to run the application (app1) from a > > network drive. I understand what the exception is and how to fix it by > > granting the application permission on each client. This is a related but > > different question. > > > > app1 generates the following dialog: > > "app1.exe - CLR Debugging Services > > Application has generated an exception that could not be handled. > > Process id=, Thread id=. > > Ok to end, Cancel to debug" > > > > Totally useless. > > > > I recently wrote another app (app2) which needed to be granted permission to > > run across a network, but forgot to grant it. Having forgotten, I get the > > following dialog: > > > > "Microsoft .NET Framework > > The application attempted to perform an operation not allowed by the > > security policy. The operation required the SecurityException. To grant this > > application..." (what follows is a great deal more useful information) > > > > A very informative and useful dialog. > > > > My question is: > > > > Why am I getting two different dialogs for the same thing? > > I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). > > > > In the case of app1, the only way to discover what the exception class is, > > is to launch the debugger. It is System.Security.SecurityException. > > In the case of app2, the dialog itself contains all the information you > > need, including the class of the exception. It is > > System.Security.Permissions.RegistryPermission. > > > > There IS no way to trap these exceptions and display to the user something > > useful (which I would like to do for app1) because they occur outside of Main. > > > > What's up with this? > > You are correct in that case.
If you are able to lauch the app. from a commandline, you will see the errordetails presented in the console window however. And this is regardless that the Main is never called due to security exception. -- Show quoteHide quotergds. /Claus Konrad MCSD.NET (C#) "Tergiver" wrote: > And one other thing: > The help documentation for AppDomain.UnhandledException says you need > SecurityPermission to add a handler to the event. Therefore, it's a circular > problem. Adding this line would cause the unhandled exception which would > occur outside your ability to trap it which would cause the unhandled > exception... > > "Claus Konrad [MCSD]" wrote: > > > The very last resort to handle an "unhandled" exception is in your AppDomain. > > Implement an eventsink for this event: > > > > AppDomain.CurrentDomain.UnhandledException += new > > UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); > > > > Here you could potentially handle any "unhandled" exceptions, potentially > > presenting some logging mechanism for this. > > > > -- > > rgds. > > /Claus Konrad > > MCSD.NET (C#) > > > > > > "Tergiver" wrote: > > > > > An exception occurs when attempting to run the application (app1) from a > > > network drive. I understand what the exception is and how to fix it by > > > granting the application permission on each client. This is a related but > > > different question. > > > > > > app1 generates the following dialog: > > > "app1.exe - CLR Debugging Services > > > Application has generated an exception that could not be handled. > > > Process id=, Thread id=. > > > Ok to end, Cancel to debug" > > > > > > Totally useless. > > > > > > I recently wrote another app (app2) which needed to be granted permission to > > > run across a network, but forgot to grant it. Having forgotten, I get the > > > following dialog: > > > > > > "Microsoft .NET Framework > > > The application attempted to perform an operation not allowed by the > > > security policy. The operation required the SecurityException. To grant this > > > application..." (what follows is a great deal more useful information) > > > > > > A very informative and useful dialog. > > > > > > My question is: > > > > > > Why am I getting two different dialogs for the same thing? > > > I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). > > > > > > In the case of app1, the only way to discover what the exception class is, > > > is to launch the debugger. It is System.Security.SecurityException. > > > In the case of app2, the dialog itself contains all the information you > > > need, including the class of the exception. It is > > > System.Security.Permissions.RegistryPermission. > > > > > > There IS no way to trap these exceptions and display to the user something > > > useful (which I would like to do for app1) because they occur outside of Main. > > > > > > What's up with this? > > > Is this perhaps a .NET 1.1 issue? Something that might have been corrected in
..NET 2.0? By corrected I mean a) displaying a useful dialog regardless of the type of security exception or b) giving us a way to trap exceptions that occur in the startup code (outside of Main being called). I don't have access to a 2.0 compiler to test it, but would strongly consider upgrading if need be. Uninformative error dialogs are a big pet peeve of mine and I try to do everything I can to eliminate them. Show quoteHide quote "Claus Konrad [MCSD]" wrote: > You are correct in that case. > If you are able to lauch the app. from a commandline, you will see the > errordetails presented in the console window however. And this is regardless > that the Main is never called due to security exception. > -- > rgds. > /Claus Konrad > MCSD.NET (C#) > > > "Tergiver" wrote: > > > And one other thing: > > The help documentation for AppDomain.UnhandledException says you need > > SecurityPermission to add a handler to the event. Therefore, it's a circular > > problem. Adding this line would cause the unhandled exception which would > > occur outside your ability to trap it which would cause the unhandled > > exception... > > > > "Claus Konrad [MCSD]" wrote: > > > > > The very last resort to handle an "unhandled" exception is in your AppDomain. > > > Implement an eventsink for this event: > > > > > > AppDomain.CurrentDomain.UnhandledException += new > > > UnhandledExceptionEventHandler(CurrentDomain_UnhandledException); > > > > > > Here you could potentially handle any "unhandled" exceptions, potentially > > > presenting some logging mechanism for this. > > > > > > -- > > > rgds. > > > /Claus Konrad > > > MCSD.NET (C#) > > > > > > > > > "Tergiver" wrote: > > > > > > > An exception occurs when attempting to run the application (app1) from a > > > > network drive. I understand what the exception is and how to fix it by > > > > granting the application permission on each client. This is a related but > > > > different question. > > > > > > > > app1 generates the following dialog: > > > > "app1.exe - CLR Debugging Services > > > > Application has generated an exception that could not be handled. > > > > Process id=, Thread id=. > > > > Ok to end, Cancel to debug" > > > > > > > > Totally useless. > > > > > > > > I recently wrote another app (app2) which needed to be granted permission to > > > > run across a network, but forgot to grant it. Having forgotten, I get the > > > > following dialog: > > > > > > > > "Microsoft .NET Framework > > > > The application attempted to perform an operation not allowed by the > > > > security policy. The operation required the SecurityException. To grant this > > > > application..." (what follows is a great deal more useful information) > > > > > > > > A very informative and useful dialog. > > > > > > > > My question is: > > > > > > > > Why am I getting two different dialogs for the same thing? > > > > I'm compiling both programs with the same compiler (using VS7.1, .NET1.1). > > > > > > > > In the case of app1, the only way to discover what the exception class is, > > > > is to launch the debugger. It is System.Security.SecurityException. > > > > In the case of app2, the dialog itself contains all the information you > > > > need, including the class of the exception. It is > > > > System.Security.Permissions.RegistryPermission. > > > > > > > > There IS no way to trap these exceptions and display to the user something > > > > useful (which I would like to do for app1) because they occur outside of Main. > > > > > > > > What's up with this? > > > >  
Other interesting topics
accessing emails using owa ... traceable?
X.509 Certificate store - getting - creating certs System.String vs SecureString Security problems in .Net web application Kerberos Token Renewal WinForm user authentication encryption prob Help!! InvalidOperationException in GetProcessesByName!! Can I retrieve Unix box OS info using DirectoryEntry Property OS? Move.file |
|||||||||||||||||||||||
