CODEWITHSUNDEEP
.net
Chris Parker
Chris Parker

Reputation: 33

Application has generated an exception that can't be handled

Getting this error when transferring a program to a new domain and new servers, and only for a few users:

"Request for the permission of type System.Security.Permissions.FileIOPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed."

at System.Security.CodeAccessSecurityEngine.CheckHelper(PermissionSet grantedSet, PermissionSet deniedSet, CodeAccessPermission demand, PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Windows.Forms.FileDialog.set_Title(String value)
at mainForm.InitializeComponent() in C:\MyProjects\DTSExecuter.root\DTSExecuter\DWMaintenance\mainForm.vb:line 88
at mainForm..ctor() in C:\MyProjects\DTSExecuter.root\DTSExecuter\DWMaintenance\mainForm.vb:line 16
at mainForm.Main() in C:\MyProjects\DTSExecuter.root\DTSExecuter\DWMaintenance\mainForm.vb:line 4

My machine runs the application just fine, as do other users, but there are a small few users who get an "Application has generated an exception that could not be handled." error box, and when debugging it returns the above error. This is a legacy application that we may not have access to source code for, and it just changed connection strings within the internal connection manager. That was the only change to the application other than running on a new domain.

Upvotes: 1

Views: 5356

Answers (3)

Scott Chamberlain
Scott Chamberlain

Reputation: 127603

I have run in to this before myself. If the starting location for the Open/SaveFileDialog is a network path and the account running the application does not have permissions to read the network path it will throw this exception.

Just set the value of InitalDirectory to something safe (like Environment.GetFolderPath(Environment.SpecialFolder.Desktop)) and it should fix the problem.

After re-reading the question, I see you can not change the source. The there is only two things I can suggest. The users who are having problems, have them use a shortcut to launch the program and set the Working Directory to a local path. If the original programmer did not set a InitalDirectory it will default to the working directory.

The other thing to check is you said you moved to a new domain, make sure the users have permissions to whatever folder the program is trying to talk to. Perhaps the permissions where not migrated over correctly.

After seeing the comment in XPD's answer I think this is what is happening:

  1. A user connects to \\Foo\Bar\ and manually enters a username and password.
  2. The user starts the program from the network share \\Foo\Bar\Baz.exe
  3. The program loads itself in to RAM and executes with the working directory of \\Foo\Bar\
  4. The loader sees that the program needs to run elevated and it gives a UAC prompt and re-executes the program as a new credential
  5. The user opens a open file dialog and no InitalDirectory was set for the dialog. it uses the working directory set from step #4.
  6. Because the new credential from step #4 does NOT get a copy of the security token generated from step #1, the AppDomain of the program does not have rights to access \\Foo\Bar\.
    1. If the user had the dialog open and they navigated to the path by hand it would have re-prompted for credentials.
    2. However, because the InitalPath was set to the working directory the error happens before the UI can ask for credentials and a FileIOPermission execption is thrown.

There is four ways to fix this, in decreasing order of preferred options.

  1. Modify the original program to use the user's desktop as the InitialDirectory for the dialog
  2. Modify the working directory of the program when it starts (like via starting from a shortcut and specifying it)
  3. Modify permissions on \\Foo\Bar so that the user does not need to manually enter credentials to connect to it.
  4. Disable UAC.

Upvotes: 2

XPD
XPD

Reputation: 1215

Problem seems to be in setting the title bar of an Open/SaveFileDialog instance. Looks like there is a path that cannot be accessed by the this app. It could be a resource file that is used to set the title of this file dialog. Give the necessary directory and file permissions to the users.

Upvotes: 1

criticalfix
criticalfix

Reputation: 2870

Figure out what File I/O path it is trying to access in mainForm.vb, and give the relevant users the necessary directory permissions in this path.

Upvotes: 0

Related Questions