为什么.NET 4.0程序在安装了.NET 4.5的Windows Server 2012计算机上会产生system.unauthorizedAccess错误？

Question

I'm getting an error that seems to only occur on machines running Windows Server 2012 . My application was written for a .NET 4.0 environment. My hypothesis is something in the .NET 4.5 isn't playing nicely with my application. I have no other ideas.

The application is designed to create PDF files. It will do this by calling multiple instances of itself. The main application will call another EXE file with a set of parameters that indicate which PDF files to create.

In this way we can call multiple EXE files, speeding up the process. For testing purposes, I can disable the calls to outside programs by changing a setting this will create all the PDF files with the same program, just more slowly.

The PDF files will be saved onto a local hard drive. The user should have access to all local drives and all administrator privileges. There are no hidden folders.

As soon as the main application goes to call a new instance of itself, it will crash. See the picture below. Either it can't use the EXE file, or it can't write to the local drive. I'm not sure which; if I need to create a log I will, thus I can determine if the application can't call the EXE file or if the application can't write to the local drive.

However, if I run the same application as administrator it runs correctly. Running as administrator isn't a viable solution for the long term. This makes me think it's not really a .NET issue.

Another thing, if I change the setting to create all the PDF files internally it will run correctly. This doesn't require the elevated privileges. This proves that the user should have access to the drive.

The application that has run stably(ish) for months off an older system Windows Server 2003 with .NET 4.0 installed.

I'm attempting to move the application to a new server, Windows Server 2012, by default .NET 4.5 or above is installed.

I have no debugger on the target system. Everything runs fine on my development environment and from the old production environment.

Answer 1

The problem ended up being I was referencing a shared local drive. For some reason I did not have permission on the share drive to write anything. I changed the output path from \\\\"c-drive\\ to c:\\... . That fixed the problem.