WPF .NET application breaks with error Could not load file or assembly '' or one of its dependencies

asked 2023-01-04T14:45:07.963+00:00
Arni Jonsson 1 Reputation point


I have a C# WPF .NET application that uses a 3rd party SDK called PaymentSDK.dll which I include and reference inside the application project.
The application runs all fine and smooth on my development computer and also in some of my customer computers in Production/Release.
However on some computers the application runs into the infamous error: "Could not load file or assembly 'PaymentSdk.dll' or one of its dependencies. The specified module could not be found.".

I have found many threads where this error is discussed but none have described my issue.

I took a look in the AppData folder in my client's computer and it seems that the PaymentSDK is there.
I took a look at the PaymentSDK's manifest file and found the following dependencies and tried to add a BindingRedirect in App.config for all these dependencies like so:


I updated .NET, to 4.8. The SDK requires .NET 4.6+.

I checked the event viewer on the faulting computer and I noticed the following error along with the previous System.IO.FileNotFoundException.

Faulting application name: ReglaPOS2.exe, version:, time stamp: 0x639c5f20
Faulting module name: KERNELBASE.dll, version: 10.0.17763.3770, time stamp: 0x21e9d433
Exception code: 0xe0434352
Fault offset: 0x001256b2
Faulting process id: 0x16f0
Faulting application start time: 0x01d9138f01a13723
Faulting application path: C:\<User-Path>\AppData\Local\Apps\2.0\72M7LWOQ.VOJ\L66XQ8J4.DE6\regl..tion_0000000000000000_0003.0008_4e96cbfa5e9538a8\ReglaPOS2.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 919e9aed-305f-4468-a852-009901923425
Faulting package full name:
Faulting package-relative application ID:

I'm not sure if it's connected to the other error.

Do you have any explanations on why it could be happening on some computers and not on others and/or any helpful advice on trying to solve this?

Many thanks,

A language based on Extensible Markup Language (XML) that enables developers to specify a hierarchy of objects with a set of properties and logic.
556 questions
No comments
{count} votes

2 answers

Sort by: Most helpful
  1. answered 2023-01-04T16:28:21.757+00:00
    Michael Taylor 37,366 Reputation points

    What bitness is your EXE being compiled at (x86, x64, AnyCPU)? What is the bitness of the PaymentSDK? If your app is AnyCPU but the PaymentSDK only works in x86 and you attempt to run the app on an x64 machine then it'll fail.

    A versioning issue seems unlikely if it works on some machines and not others but you can quickly rule this out by looking at the assembly version that is deployed on a non-working machine. If the version doesn't match what works on other machines then it is a versioning issue and binding redirects are the solution. But, again, this seems unlikely if it works for some clients.

    The next thing to look at is whether the client machines actually have .NET 4.8 installed or not. The app itself will require CLR v4 but any version of .NET 4.x would work here. However if the app attempts to use something that is only in a later version then it would fail, although I would be a little surprised at the error.

    The event viewer error is a general software error and by itself not useful. However normally .NET reports the actual exception so maybe there are more errors you aren't seeing?

    Finally, take a look at the dependencies that your PlatformSDK relies on. Does it require third party libraries (such as C++) to be installed? If so then you need to ensure they are installed as well. Again I would be a little surprised with the FnF exception but I've seen more bizarre behavior before.

  2. answered 2023-01-05T03:21:33.41+00:00
    Hui Liu-MSFT 14,556 Reputation points Microsoft Employee

    Hi, @Arni Jonsson . Welcome Microsoft Q&A.
    As cooldadtx said, the cause of Exception code: 0xe0434352 may be .NET Framework, Platform Target or 3rd Party Conflict, etc. You could try to check whether the .NET Framework and Platform of the application are consistent or have no conflicts.

    On a 86-bit Windows operating system: Executables and DLL that are compiled with the Any CPU execute on the 32-bit CLR. On a 64-bit Windows operating system: A DLL compiled with the Any CPU executes on the same CLR as the process into which it's loaded. Executables that are compiled with the Any CPU execute on the 64-bit CLR. The Target Platform of the program and the referenced DLL should be consistent at runtime. Generally speaking, we can set the Target Platform of the program to be consistent with the deployed operating system according to actual needs and the DLL is preferably Any CPU. The special deployment environment requires special consideration.

    It may also be that the installed application is corrupted, you can try to reinstall the problematic application.


    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    No comments