How do I fix a .NET windows application crashing at startup with Exception code: 0xE0434352?

I've built a .NET Windows Forms application in Visual Studio 2010. I also built a corresponding setup/install package via Visual Studio 2010. This is built as a 32-bit (x86) application. (We make use of third-party Windows Forms controls that are 32-bit only).

I am able to run the setup package and deploy successfully to other Windows 7 64-bit environments and 32 bit Windows XP boxes. The installed application runs fine on these.

However, when I attempt to run Windows Server 2008 R2 - 64 bit, the application crashes at startup. It installed successfully via the installer without any errors.

It appears to crash when loading the application. I put a message box as the first line in the application to see if it got past loading. The message box doesn't show up, so I assume that it occurs during loading/init of the application.

So far I haven't found much to go on. From the Details I see the following:

Exception Code: E0434352

I've fished around/googled to see if there was anything obvious, but I saw nothing. I saw some references to a possible stack overflow in the CLR.

The Windows Forms application is built with the following references:

• DevExpress
• Infragistics Winforms controls
• ORACLE DataAccess DLL
• RabbitMQ

What is the issue? How do I approach figuring this out? How do I debug to get more useful information?

If you are getting that error from Event Viewer, you should see another error event (at least one) from the Source ".NET Runtime". Look at that error message as it will contain the Exception info.

0xE0434352 is the exception code for all .NET exceptions so that won't tell you much. How did you got this exception code? The event log?

Your best bet is to use a debugger to get more information. If the Visual Studio debugger won't help you, then you might need to check out WinDbg with SOS. See here and here for an introduction. Let it break on the exception, and see if you can get more information on the why.

If you suspect it is an issue when loading assemblies you might want to check out the Fusion Log.

I'm not sure if this will help anyone or not, but since it was my problem, I figure it's worth mentioning:

I was getting this error, and it turned out to be a problem with the platform for which the EXE was built. We had it building for x86, and it needed to be x64, because of an Oracle reference in the project. When we made that change, the problem went away. So, see if you have any similar conflicts.

It looks like this error 0xe0434352 applies to a number of different errors.

In case it helps anyone, I ran into this error when I was trying to install my application on a new Windows 10 installation. It worked on other machines, and looked like the app momentarily would start before dying. After much trial and error the problem turned out to be that the app required DirectX9. Though a later version of DirectX was present it had to have version 9. Hope that saves someone some frustration.

I was fighting with this a whole day asking my users to run debug versions of the software. Because it looked like it didn't run the first line. Just a crash without information.

Then I realized that the error was inside the form's InitializeComponent.

The way to get an exception was to remove this line (or comment it out):

System.Diagnostics.DebuggerStepThrough()

Once you get rid of the line, you'll get a normal exception.

I was getting this when the app deployed. In my case, I chose "This is a full trust application" on the project security tab, and that fixed it.

> Issue:

.Net application code aborts before it starts its execution [Console application or Windows application]

>Error received: Aborted with Error code "E0434352"

Exception: Unknown exception

>Scenario 1:

When an application is already executed, which have used some of the dependent resources and those resources are still in use with the application executed, when another application or the same exe is triggered from some other source then one of the app throws the error

>Scenario 2:

When an application is triggered by scheduler or automatic jobs, it may be in execution state at background, meanwhile when you try to trigger the same application again, the error may be triggered.

>Solution:

Create an application, when & where the application release all its resources as soon as completed Kill all the background process once the application is closed Check and avoid executing the application from multiple sources like Batch Process, Task Scheduler and external tools at same time. Check for the Application and resource dependencies and clean up the code if needed.

We got this error when the connection string to our database was incorrect. The key to figuring this out was running the dotnet blah.dll which provided a stacktrace showing us that the sql server instance specified could not be found. Hope this helps someone.

To fix the issue for me (as a number of applications started to throw this exception all of a sudden, for example, CorelDraw X6 being one), I uninstalled the .NET 4.5 runtime and installed the .NET 4 runtime. The two versions cannot be installed side by side, but they use the same version numbers in the GAC. This causes issues as some of the functions have been depreciated in 4.5.

DLL Hell has returned...

So.. I had noticed in event viewer that this crash corresponded to a "System.IO.FileNotFoundException" error.

So I fired ProcMon and noticed that one of the program dlls was failing to load vcruntime140. So I simply installed vs15 redist and it worked.

I know this is a somewhat old thread, but I had this problem too with a c#/WPF app I was creating. The app worked fine on the development machine, but would not start on the test machine. The Application Log in the Event Viewer gave a somewhat nebulous .NET Runtime error of System.IO.DirectoryNotFoundException.

I tried using some debugging software but the app would not stay running long enough to attach the debugger to the process. After banging my head against my desk for a day and looking at many web pages like this one, what I wound up doing to troubleshoot this was to install VS2019 on my test machine. I then dragged the .exe file from its folder (it was deep in the Users[user]\AppData\Apps\2.0... folder) to the open VS2019 instance and went to start it from there. Immediately, it came up with a dialog box giving the exception and the cause.

In my case, when I added an icon to one of the forms, the complete path to the icon was placed into the XAML instead of just the icon name. I had copied the icon file into the project folder, but since the project folder does not exist on the test machine, this was the root cause of the error. I then removed the path from the XAML, leaving just the icon name one, rebuilt the solution and re-published it, and it ran just fine on the test machine now. Of course there are many causes besides what gave me the error, but this method of troubleshooting should hopefully identify the root cause of the error, since the Windows Event Viewer gives a somewhat vague answer.

To summarize, use Visual Studio on the test machine as a debugger of sorts. But, to get it to work right, I had to drag the .exe file into the IDE and Start (run) it from there. I believe this will also work with VS2017 as well as VS2019. Hopefully this helps someone who is still having this issue.

When running a command line application it would immediately exit, and I saw this exception in the Event Viewer but received no other feedback. In my case, running the command prompt as administrator solved the problem.

I believe one of the takeaways from this is simply that you may get this exception due to a permission issue.

A few hours later we had the identical exception with a newer version of the console application for a different reason. This time it turned out to be a dll version incompatibility. Using the required newer dll version solved the problem.

Perhaps this generic error comes up due to code that is not handling exceptions gracefully; with the best fix likely being to handle exceptions at least well enough to provide better error messages.