I am using VS2012 with VB.NET for a winfowms app, using Active Directory roles.
Running the program as a user without permissions, I am getting an (expected) security exception when trying to launch this form.
I have a form that looks like this:
<PrincipalPermission(SecurityAction.Demand, Role:=Security.Roles.ADMINISTRATORS)> _
<PrincipalPermission(SecurityAction.Demand, Role:=Security.Roles.CORRECTIVE_ACTION_EDITORS)> _
<PrincipalPermission(SecurityAction.Demand, Role:=Security.Roles.GRIEVANCE_EDITORS)> _
<PrincipalPermission(SecurityAction.Demand, Role:=Security.Roles.ABOLISHMENT_EDITORS)> _
Public Class EmployeeInformationForm
...
End Class
The call to the code looks like this:
Private Sub SendEmployeeIDToEmployeeInformationForm(ByVal ID_in As String, ByVal employeeRecord_in As String)
...
If Not formFound Then
' Create a new instance of the child form.
Dim ChildForm As New EmployeeInformationForm(ID_in, employeeRecord_in) ' ** throws expected security exception here**
Try
' Make it a child of this MDI form before showing it.
ChildForm.MdiParent = Me.MdiParent
...
ChildForm.Show()
Catch ex As Exception
ChildForm.Close()
Throw
End Try
End If
After 15 or 16 attempts (or maybe the variable is "after about 1 minute"?) the program crashes.
UPDATE: after more input of any kind the program crashes. I have debugged the code as the user without permissions, and was able to capture the exception being thrown - apparently from nowhere. It is very weird saying "The call stack contains only external code", and displays the following:
This thread is stopped with only external code frames on the call stack. External code frames are typically from framework code but can also include other optimized modules which are loaded in the target process.
Call stack with external code
mscorlib.dll!System.Security.Permissions.PrincipalPermission.ThrowSecurityException()
mscorlib.dll!System.Security.Permissions.PrincipalPermission.Demand()
mscorlib.dll!System.Security.PermissionSet.DemandNonCAS()
[Native to Managed Transition]
[Managed to Native Transition]
OHRC Database.exe!OHRC_Database.EmployeeInformationForm.Dispose(Boolean disposing)
System.dll!System.ComponentModel.Component.Finalize()
It seems to imply it is having a hard time closing the form? Can anyone tell me why it is throwing this exception?
The exception is being thrown from the finalization thread (the Finalize() call in your exception stack trace is the hint for this), and the user identity on that thread doesn't have the right permissions either. See http://msmvps.com/blogs/calinoiu/archive/2006/01/07/why-is-my-application-coughing-up-a-securityexception-after-my-code-stops-running.aspx for further details and a fix.
HTH,
Nicole
Related
I have a Winforms application with a primary form that contains (among other things) a Telerik DocumentTabStrip. These tabs are used to hold user controls or web pages (via a web browser control). It has worked fine for quite a while, but I'm running into an issue now.
I recently switched the web browser control from the built-in .NET web browser based on IE to CefSharp. Since doing so, I've noticed that occasionally when trying to add the DocumentWindow to the DocumentTabStrip, the call will hang indefinitely (in debug) or crash outright (running the app normally). This only appears to happen when opening a DocumentWindow that contains the browser control, not any other user controls. The actual call itself is below.
I'm at a bit of a loss as to how to even begin to debug this, since there's no error that gets received - it just hangs inside the Controls.Add() method indefinitely. Any advice would be appreciated.
Private dts As New Telerik.WinControls.UI.Docking.DocumentTabStrip
Try
dts.InvokeIfRequired(Sub()
Dim docWindow As Telerik.WinControls.UI.Docking.DocumentWindow = Nothing
Dim ctrl As ucBaseControl = Nothing
Dim browser As ucBrowser = Nothing
Dim isBrowser As Boolean = False
docWindow = New Telerik.WinControls.UI.Docking.DocumentWindow
docWindow.BackColor = Color.FromArgb(89, 89, 89)
'Do various stuff to determine the type of control to load (ctrl or browser), then setup the applicable control
If isBrowser Then
'Place the browser into the Document Window.
If Not IsNothing(browser) Then
browser.Dock = DockStyle.Fill
docWindow.Controls.Add(browser)
End If
Else
'Place the ctrl into the Document Window.
ctrl.Dock = DockStyle.Fill
docWindow.Controls.Add(ctrl)
End If
'Add the DocumentWindow to the DocumentTabStrip
' Ensure DockWindow not disposed due to lag in bringing up
If IsNothing(docWindow) OrElse docWindow.IsDisposed Then
Exit Sub
End If
Try
docWindow.Padding = New Padding(0)
dts.TabStripElement.Children(0).Children(1).Padding = New Padding(0)
dts.Controls.Add(docWindow) 'This is where the issue is. It only happens sporadically here.
Catch ex As Exception
'Code to log any exceptions here. In the problem described here, no exception is ever generated, though.
End Try
'Bring the control to the front and focus it, here...
End Sub)
Catch ex As Exception
'Error handling code here'
End Try
I'm assuming InvokeIfRequired is an extension method you've created for Controls. Note that if it relies on Invoke, that is a synchronous call, instead use BeginInvoke (see: What's the difference between Invoke() and BeginInvoke())
No exception was ever thrown because you were suffering from deadlock
I would like to catch an unhandled exception that causes my application to silently close.
I have read that there is
Application.Current.DispatcherUnhandledException
My application however uses a form to run and the application framework, not a sub main.
The example on MSDN (http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx) seems to rely on a sub main, as it seems to me.
Could somebody tell me how to install the exception handler for a project that uses the application framework?
I have tried the following:
I have changed my application to use a Sub Main instead and used the following code:
Public Sub Main()
' Set the unhandled exception mode to force all Windows Forms errors to go through'
' our handler. '
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException)
' Add the event handler for handling UI thread exceptions to the event. '
AddHandler Application.ThreadException, AddressOf frmMain.UIThreadException
' Add the event handler for handling non-UI thread exceptions to the event. '
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf frmMain.CurrentDomain_UnhandledException
' Runs the application. '
Application.Run(New frmMain())
End Sub
However, the error I am getting is:
"The thread exception mode can no longer be changed as soon as controls were created in this thread".
You could use a Try Catch to avoid an application from closing by exception. You could try something like
Try
Console.WriteLine("Hello, world!")
Dim A As Integer = 0
Dim I As Integer
For I = 1 to 500000000000
A*=I
Next
Catch ex As Exception
Console.WriteLine("Error occurred")
End Try
This is a little example in a Console Application program, but you will be able to use something like in your project.
The generic Exception catches every kind of exception you could have, so also Application.Current.DispatcherUnhandledException.
Your program shouldn't crash anymore with a try statement.
Hope it helps.
It is good practice to also register an event handler for the case that some exception does not get caught at runtime.
It allows you to log the exception cause and to exit application in a controlled manner.
But as already said, you should primarily use Try Catch statements to catch exceptions in first instance.
I have a C++ application in which I'm trying to show a WPF form (named WSWindow), specifically one that inherits from the System.Windows.Window class so that I can get the window handle using the WindowInteropHelper class.
My problem is that whenever I make the call to the method below, the application crashes.
public IntPtr GetHWND()
{
if (ivWindow == null)
{
ivWindow = new WSWindow();
ivWindow.WindowStartupLocation = WindowStartupLocation.Manual;
ivWindow.Show();
}
IntPtr handle = new WindowInteropHelper(ivWindow).Handle;
return handle;
}
I believe the WSWindow constructor is causing the crash. On the C# side of things there's a WSService class that calls the WSWindow constructor, and if I put the WSWindow constructor in the WSService constructor, the C++ app crashes on calling the WSService constructor (something that works fine when the WSService constructor does not contain the WSWindow constructor). Also, in addition to calling the above method, I've tried the following in the C++ app:
WSWindow^ w = gcnew WSWindow();
and there are log lines immediately after this line that don't get written to the log file.
In the WSWindow contructor, there's a call to InitializeComponents, which is generated code in the WSWindow.g.cs file:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public void InitializeComponent() {
if (_contentLoaded) {
return;
}
_contentLoaded = true;
System.Uri resourceLocater = new System.Uri("/Project_Name;component/wswindow.xaml", System.UriKind.Relative);
#line 1 "..\..\WSWindow.xaml"
System.Windows.Application.LoadComponent(this, resourceLocater);
#line default
#line hidden
}
At first I thought maybe the call to LoadComponent was failing because the uri couldn't be resolved, but I added a log line in the WSWindow constructor before the call to InitializeComponent() which gets written when the WSWindow is created from a Windows Forms test app, but not when the WSWindow is created by a call from the C++ app, so it seems like nothing in the WSWindow constructor even gets executed, it just crashes right away.
There's no problem with references that I can tell; I've written a couple test methods, one that returns an int, one a simple custom Window object with width/height members and successfully called both from the C++ app.
I've also successfully retrieved the handle to the WSWindow when it is compiled as a WPF app and run before launching the C++ app, but I need to be able to create the WSWindow from a call within the C++ app.
I've spent days on this problem trying to figure out why the crash is occurring with no luck. I'm hoping someone that reads this knows something about WPF that could be causing this issue, or a known issue between C++/CLI and WPF controls. I'm totally out of ideas.
Additional info: When I start the C++ app and attach VS to the process, nothing shows up in the call stack (a separate problem for me to work on), but I noticed a couple exceptions that look like they might be related:
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b158..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b608..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
The solution was that I needed to mark the thread making the call to create/show the WPF Window with the [STAThread] attribute.
I'm using a serial port with a Serial Object and sometimes I get this error.
UnauthorizedAccessException: Access to the port is denied.
with a stack trace of:
at System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)
at System.IO.Ports.InternalResources.WinIOError()
at System.IO.Ports.SerialStream.Dispose(Boolean disposing)
at System.IO.Ports.SerialStream.Finalize()
It doesn't occur at any line of code (within my code at least) so I'm not sure how to trap it. I figure what is happening is the serial (via USB) port is being physically unplugged/disconnected for a split second and is throwing everything into whack.
I can click Continue on the error which I'm debugging and everything is fine. Communication with the serial device is flawless otherwise. But when the program is actually published, deployed and running it gives me several error messages and is all ugly for the user.
How can I trap this error/what can I do to prevent it in the first place?
Thanks
I encounter the same exception and stack trace in my WinForms application when used with a USB-to-serial converter. I can consistently recreate it by
creating an instance of SerialPort
calling SerialPort.Open,
removing the USB-to-serial converter,
closing the app (which calls SerialPort.Dispose)
My suspicion is that the exception is being thrown in SerialPort's finalizer.
Others have experienced the same symptoms - see here.
To work around I followed the recommendation of Kuno and KyferEz (from link above) to implement my own ExtSerialPort. This inherits SerialPort, overrides the Dispose method and (using reflection) disposes the SerialPort's internalSerialStream.
Imports System.IO.Ports
Public Class ExtSerialPort
Inherits SerialPort
Public Sub New()
MyBase.new()
End Sub
Public Sub New(ByVal portName As String)
MyBase.New(portName)
End Sub
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
Dim mytype As Type = GetType(SerialPort)
Dim field As Reflection.FieldInfo = mytype.GetField("internalSerialStream", Reflection.BindingFlags.Instance Or Reflection.BindingFlags.NonPublic)
Dim stream As Object = field.GetValue(Me)
If stream IsNot Nothing Then
Try
stream.Dispose()
Catch ex As Exception
End Try
End If
MyBase.Dispose(disposing)
End Sub
End Class
When working on ASP.NET 1.1 projects I always used the Global.asax to catch all errors. I'm looking for a similar way to catch all exceptions in a Windows Forms user control, which ends up being a hosted IE control. What is the proper way to go about doing something like this?
You need to handle the System.Windows.Forms.Application.ThreadException event for Windows Forms. This article really helped me: http://bytes.com/forum/thread236199.html.
Currently in my winforms app I have handlers for Application.ThreadException, as above, but also AppDomain.CurrentDomain.UnhandledException
Most exceptions arrive via the ThreadException handler, but the AppDomain has also caught a few in my experience
If you're using VB.NET, you can tap into the very convenient ApplicationEvents.vb. This file comes for free with a VB.NET WinForms project and contains a method for handling unhandled exceptions.
To get to this nifty file, it's "Project Properties >> Application >> Application Events"
If you're not using VB.NET, then yeah, it's handling Application.ThreadException.
To Handle Exceptions Globally...
Windows Application
System.Windows.Forms.Application.ThreadException event
Generally Used in Main Method. Refer MSDN Thread Exception
Asp.Net
System.Web.HttpApplication.Error event
Normally Used in Global.asax file. Refer MSDN Global.asax Global Handlers
Console Application
System.AppDomain.UnhandledException event
Generally used in Main Method. Refer MSDN UnhandledException
Code from MSDN: http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-2
Sub Main()
Dim currentDomain As AppDomain = AppDomain.CurrentDomain
AddHandler currentDomain.UnhandledException, AddressOf MyHandler
Try
Throw New Exception("1")
Catch e As Exception
Console.WriteLine("Catch clause caught : " + e.Message)
Console.WriteLine()
End Try
Throw New Exception("2")
End Sub
Sub MyHandler(sender As Object, args As UnhandledExceptionEventArgs)
Dim e As Exception = DirectCast(args.ExceptionObject, Exception)
Console.WriteLine("MyHandler caught : " + e.Message)
Console.WriteLine("Runtime terminating: {0}", args.IsTerminating)
End Sub