.Net Application SideBySide loading fails COMException (0x80040154) - c#

My .Net 4.5.2 WPF Application is deployed to C:\Program Files\Folder A\FolderB. Its copied to that location by a custom deployment service that is basically a copy job with some additional features. The application itself is xcopy deployable, given you have the required C++ runtimes, .Net Framework installed.
The application includes several com components, registered via the application manifest file, which used to work just fine. After an update to the applications binary files, several calls in the form System.Activator.CreateInstance fail
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
If i simply rename the application folder to c:\Program Files\FolderA\FolderC everything is working correctly
Attaching ProcessMonitor and WinDbg, i can trace that the application is searching the registry for the given classid, doesnt find it and then, if started from the first folder fails as described above. Started from the renamed or copied folder the process loads the associated dll and just goes on.
Any hints on diagnosing this issue?

To anyone struggeling as I did: as far as i currently see it, the problem was the SideBySide Cache.
In short, Windows caches the manifest information for an application, and if it determines the application has not changed, uses the cache (you will notice that the existing external manifest is never loaded by your process).
In my case the executable did not change, but the rest of the application, including the manifest information.
The solution is to touch the modification date of the executable, causing the cache to become invalidated.
Basically also answered in this question

Related

BadImageFormatException Could not load file or assembly ... An attempt was made to load a program with an incorrect format

I have .NET 5 project which includes C++/CLI DLL, which includes C++ DLL, which includes opencascade DLLs. All these projects are built for the x64 platform. I've published this solution to my local folder and then set up IIS server everything works fine. But when I've tried to upload my project to two different hostings (https://www.smarterasp.net/ and azure) I've got this error. Project crashes when it starts use C++/CLI dll(using namespace C++/CLI). I've also set up x64 platform in azure portal.
I would appreciate any help.
Thank you Joe. Posting your suggestion as an answer to help other community members.
Project crashes because of missing DLL. Run the app and get the error.
Go to the Windows Event Viewer (Start Menu and type "Event"). In the EventViewer, under Windows Logs >> Application, you might see an error message regarding the failure. If the error is a missing DLL, it will typically tell you the name of the DLL as well.
You can refer to Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException), Troubleshooting BadImageFormatException and System.BadImageFormatException An attempt was made to load a program with an incorrect format

Unable to load DLL 'SQLite.Interop.dll' from x64/x86 but is able to load the one alongside System.Data.SQLite.dll

I have run into this weird problem. In my WCF project I have referenced a class library that uses SQLite to query some static data. Naturally that class library is using System.Data.Sqlite + System.Data.SQLite.Core + System.Data.SQLite.EF6 + System.Data.SQLite.Linq from NuGet. The WCF project itself does not do the query. It invokes a method from the class library that does it.
When I run it on my dev machine all is well. But after I deployed it to IIS on a Windows Server 2012, the exception Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) was thrown. I did search SO and found that I need to reference at least System.Data.SQLite.Core in my main WCF project and make sure it has x64 & x86 folders with the corresponding Sqlite.Interop.dll in each folder respectively. The said folders are auto-generated with the NuGet reference and are placed under bin folder. So I was happy. Deployed. And same thing happened: all is well in dev machine then unable to load DLL on the server.
I even tried referencing all NuGet packages in main WCF project to no avail. Then it occurred to me to try manually copying the dll from x64 folder to my bin root folder, right alongside wcf.dll and System.Data.SQLite.dll. Now the error message changed to Unable to load DLL 'SQLite.Interop.dll': Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) instead of not found.
After giving it all permissions, it worked!
But this behaviour strikes me as strange because in my dev machine and another test server I cannot reproduce this. Only on the prod server would this error be thrown.
Is there anything that I've overlooked? BTW I tried to turn my WCF project from targeting AnyCPU to x64 only. I tried using Enable 32-bit in the advanced setting of IIS AppPool. None worked until all DLLs are in bin root.
I might be onto something here. I did a procmon. It seems to me that the dll under x86 was found successfully. It's however, denied access on a CreateFile operation.
Now it looks like it falls onto the permission realm. On Test environment and my dev machine the AppPool has god's privilege so the problem can't be reproduced.
TL;DR
Then I went into the permission detail. I found that WCF apppool identity has Read permission only on x86\Sqlite.Interop.dll. I added the Read and execute and problem gone. You millage may vary and it could be the x64 one that needs permission.
After thoughts:
Now I'll take a few days to observe but I think that this is it. Although from procmon it says Create File failed it doesn't mean it requires write permission.
Further testing showed my permission setting was off because I used the Visual Studio Deploy feature to deploy my website. In the process it sets my website root directory to Read only.

Deploy com dependent app to azure cloud

I'm trying to deploy c# app which references at COM DLL. I know that Azure Cloud VMS are x64, so COM lib I referenced to is x64 too.
I've added .cmd file and linked it in ServiceDefinition. And looks like it is executed, because if I'm deleting .cmd file I'm getting an error of missing it.
I'm not sure about one thing: which library I should register? I mean I have a someCOM.dll. I'm referencing it in my c# project and I'm getting someCOMLib.dll in my references list. But my project doesn't contain any someCOMLib.dll. It is contain Interop.someCOMLib.dll
So I've tried to register original someCOM.dll but I'm getting error
Retrieving the COM class factory for component with CLSID {D1F73A20-01A1-431B-A135-2D2A89A3D2B3} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
And if I'm doing everything right is there any other things I may be missed?
someCOM.dll was dependent on other libs, so I added them to my projects folder with someCOM.dll. That was the most problem, because all worked fine on my machine without any additional work. That was because it is a 3rd party solution so I think their installer did all the job.
I saved my .cmd in notepad and it saved in UTF-8 by default. So when I tried to execute this cmd I get some strange symbols somewhere between my commands, so it failed.
To sum up there is some advices to somebody who face this problem and has zero level of COM etc. subject knowledge:
remove /s flag in your .cmd and execute it from your command line with admin rights. Don't forget to return /s flag back on deploy.
You will see your problem .dll guid on the error page after deploy. Just visit yout host address (with <customErrors mode="Off"> in Web.config)
Open regedit and find guid of problem .dll. There may be some helpful info.

COM class factory for component with clsid failed error 80040154

I have a weird error when running an asp.net web site.
Everytime i try to run the website, i got this error: "COM class factory for component with CLSID failed due to the following error : 80040154"
I located the dll who is giving me trouble, it's one we developed and never failed before(already used in other sites)
I try every advise on Internet, already try
Check the platform target =X86.
The OS is WS2003, 32 bits, IIS 6.0 (No need to set the run 32 bits apps).
Regsvr32 failed due to Entrypoint was not found.
Try to use regasm, succesfuly registered but not success, still send the same error.
Check the regedit, found the CLSID, check the value of Default under InProcServer32.
Try to use Gacutil, not success
Copy the dll into System32 folder
Gave FULL permissions on EVERY folder involved or suggested
The weird thing, i got the dll under the BIN folder, so, why it need to be registered?
Any suggestion would be appreciated
Since you have tried all the possible culprits, try running regmon and see the dependent DLLs being referenced by the base DLL. and for each of those DLLs, find if the registry entries/registration etc. exist.

Unable to find security.dll library on class library application

I trying to use ssl connection on class library application but i tried to authenticate
as a client to server i got following error message.
"Unable to find an entry point named 'EnumerateSecurityPackagesW' in DLL 'security.dll'."
Have any body experience about this?
Security.dll is also the same name for the Windows DLL containing the SSPI implementation, which is used for authentication. When loading DLLs, the local bin directory will be checked before the Windows directory. As a result, your System.dll is being loaded instead of the SSPI System.dll.
So if in certain situations your custom Security.dll is loaded before
c:\winnt\system32\security.dll then LoadLibrary thinks it has the dll
already loaded (since it's just a Win32 Dll, only name matter, NOT version
information). But as we know this is not the correct dll and hence the
problem.
The workaround is to change the dll name.

Categories

Resources