Every time I try to load DLL (COM) I get the following error:
LDR: LdrpWalkImportDescriptor() failed
to probe for its manifest,
ntstatus 0xc0150002
I searched a lot but found nothing.
Please I really believe in this site experts and I hope to get a solution to this problem.
I know that the problem is from manifest file but I really don't know what is it and how to fix this
I use VS2010 C++ and LoadLibrary
This is the description of the error code from ntstatus.h:
//
// MessageId: STATUS_SXS_CANT_GEN_ACTCTX
//
// MessageText:
//
// Windows was not able to process the application binding information.
// Please refer to your System Event Log for further information.
//
#define STATUS_SXS_CANT_GEN_ACTCTX ((NTSTATUS)0xC0150002L)
Look in the Windows event log for further information. A very common mishap is that the CRT runtime library that the DLL needs is not installed in your machine. Post what you see there in your question if that doesn't help. Or contact the COM component vendor or author for support, best way.
Com dlls are not loaded with loadlibrary. The system loads them itself when you do CoCreateInstance for object implemented in library.
The problem seems to be that dlls on what the com dll depends are missing.
The first and second links that Google produces for this error both suggest it is commonly caused by runtime library versioning. Both predate VS2010, but I would start by looking for a similar problem. Have you tried duplicating the analysis steps described in that first post?
(Is the DLL something that you have created? If not, maybe it actually was built with VS2008 and corresponds exactly to that post? If so, maybe you can try the compilation tweaks recommended there.)
Related
I've been making a program in Visual Studio 2012, what comes with it is that when I send my application to someone, they need the VS2012 Runtime, which sometimes they don't know where to download or what they need (for normal users "xxx.dll is missing" is very misleading).
I know exactly which dependencies my application requires (fantom.dll [Lego Mindstorms stuff] and the VC++ 2012 Redist).
I would like to show a dialog when these libraries are missing on application startup and provide the user with download links for these libraries.
Is this possible to accomplish?
Yeah you could do something like:
Move all of the code in your binary into a DLL.
Create an EXE which dynamically loads the DLL using LoadLibrary and unloads it with FreeLibrary.
If LoadLibrary fails, check if its due to missing DLLs, if so then display a MessageBox/your custom message and exit.
Of course this means your EXE project must NOT depend on the runtime itself - this shouldn't be an issue since you'll only need to call 3 win32 API's.
No it's not possible but you can create an installer for your program. The error is thrown during the loading of your program, before your code execution...
You can try with that : http://www.codeproject.com/Articles/24187/Creating-an-Installer
I can't speak for testing the VS2012 Runtime dynamically, but you can certainly validate fantom.dll dynamically. Instead of static-linking to the DLL directly, you can dynamically load it instead. You can configure your project to delay-load the DLL at run-time, and then provide a delay-load callback handler that the RTL will call if the delay-load fails. Or you can simply skip the delay-load feature and load the DLL yourself manually by calling LoadLibrary() and GetProcAddress() directly.
Sure, you can verify if a dependency exists on the deployed system. A few things come to mind...
You can see if the assembly is recognized on the running system by calling AppDomain.AssemblyResolve() . Further reading here
Another more primitive option is to call a File.Exists(your assembly path here) test, but I would advise against this as it's a bad practice to require hard-pathed installation locations.
That said, and as others have stated, it's still by far the best approach to create yourself an installation distribution.
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
I am building a project in VS2005 and several of my DLLs are failing to register. The error message I am getting in Visual Studio is:
Project : error PRJ0019: A tool returned an error code from "Registering ActiveX Control..."
which is nicely vague. When I register the DLL manually through the command line (using regsv32.exe, I get the following error:
LoadLibrary("test.ocx") failed - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.
I ran Dependency Walker (depends.exe) on the culprit .ocx file but it isn't showing any obvious problems.
I have also done a re-build but I'm still getting the same problem.
Any suggestions as to how I could determine the cause of this failure to register?
Microsoft had recently released a Security Update for ATL (KB971090). It is un update on top of MSVS2005sp1 and it's both compilate-time and runtime compatibility breaker. Check if your building environment has this patch.
References:
ATL Security Update:
http://msdn.microsoft.com/en-us/visualc/ee309358.aspx
Breaking changes in ATL:
http://msdn.microsoft.com/de-de/library/ms235654.aspx
And this is a must read:
http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
Most probable is because the embedded manifests. You should take a resource explorer application and check your DLLs for the embedded manifests. It might be that one of the dependent DLLs (or your DLL) require some versions of other DLLs which don't exists.
I got this message: "This application has failed to start because the application configuration is incorrect." in case of embedded manifest mistmatches.
Probably the easiest way to troubleshoot this whole category of problem is to install Process Monitor from microsoft.com.
Process Montior lets you observe the system calls processes are making, and in this case you will be able to see if some system call is failing. For example, if you are lacking a dependency, then a CreateFile() call will be seen failing with a DLL, OCX, etc. as the filename.
Launch procmon and configure the filter to exclude events other than from regsvr32.exe, reproduce your test case, and then check the log. Look for NAME_NOT_FOUND errors in the return value column.
Do you have the C++ Redistributable Package Installed?
There are several things you can try:
try regsvr32 w/ fusion log enabled (fuslogvw.exe - it works for unmanaged dlls as well). This would give you a bit more information than depends on what external dependencies are loaded, where are they loaded from and what errors were hit.
copy the .ocx and its dependencies to the root or a first level folder and try registering from there. I don't remember details, but there was an old problem with registering a COM dll from within too deep of a path.
run regsvr32 under WinDbg. Set a breakpoint DllMain and see if it does anything funky.
If you never break on DllMain in WinDbg, set a breakpoint on module load for your dll and once it's hit, you can either step through LoadLibrary, or just set a generic load library breakpoint and check every dll after that.
I'm working on a piece of C++ software which runs on all Windows versions between Windows XP and Windows Vista. In my code, I developed a DLL which links against a standard library (the Qt library). Once my software is deployed, it's not unusual that the user doesn't have the exact same Qt build on his system but a slightly different configuration. There might be features disabled (so their Qt build doesn't export the same set of symbols) or the library might even be changed in ways which make the library binary incompatible to the original.
At some point, I'm loading my DLL via a LoadLibrary() call. This pulls in whatever Qt library is on the user's system. If I'm lucky, their Qt build is compatible with what I used while developing my DLLs, so LoadLibrary() succeeds. However, depending on the changes they did to their Qt build, the LoadLibrary() call sometimes fails with
"The specified Module could not be found."; this usually happens if their Qt build consists of less DLLs than my Qt build. So my DLL attempts to load e.g. QtFoo.dll but since this dll is not part of their Qt build, loading my DLL fails.
"The specified Procedure could not be found."; this usually happens if they changes their Qt build so that certain features are disabled, which results in less exported symbols.
My question is: how can I catch these errors gracefully? Right I'm simply using GetLastError() and then print either of the above two messages. However, it would be much more useful if I knew which module could not be found, or which procedure is missing. I noticed that when running an application in the explorer which links against a missing DLL, explorer manages to yield a nice 'The application foo could not be loaded since the required library blah.dll is missing'. Is there maybe some API available to get more information about why a LoadLibrary() call failed exactly?
Short of attaching a debugger to your process, I don't think you can. The message that typically pops up when this happens is generated internally by LoadLibrary. SetErrorMode is used in a lot of apps to inhibit messages of this form, I'm gessing that somewhere in your apps framework, its calling SetErrorMode to inhibit the OS message.
The only app ive seen generate its own verbose messages about dll load failures is MS DevStudio - which is attached as a debugger and so has access to a special stream of debug events.
At some point, I'm loading my DLL via
a LoadLibrary() call. This pulls in
whatever Qt library is on the user's
system.
Don't do this! The kind of errors you have are the lucky kind, just as easily it could corrupt memory and crash.
The canonical way of shipping a Qt application is either shipping the DLLs or linking statically. Check out the Qt deployment guide in the help files.
Later edit:
After reading your comments, I still do not recommend that you use this approach, since you can't be sure that the DLLs are binary compatible even if they load, which could lead to hard to track errors.
Nevertheless, I believe that you could intercept the LoadLibrary calls and see which ones fail. The MS Detours library can be used for this. Also see this Stackoverflow question.
To expand jeffamaphone's answer, you can try retrieving the file version details before calling LoadLibrary. You can do this using the following function:
BOOL GetFileDetails(LPCTSTR lpszPath, LPDWORD lpMajorVersion,
LPDWORD lpMinorVersion)
{
DWORD dwVersionHandle;
DWORD dwVersionSize = GetFileVersionInfoSize((LPTSTR)lpszPath,
&dwVersionHandle);
if (dwVersionSize == 0)
return FALSE;
LPBYTE lpVersion = new BYTE[dwVersionSize];
if (!GetFileVersionInfo((LPTSTR)lpszPath, dwVersionHandle,
dwVersionSize, lpVersion))
{
delete [] lpVersion;
return FALSE;
}
VS_FIXEDFILEINFO *pVersionInfo = NULL;
UINT nLength;
if (!VerQueryValue(lpVersion, _T("\\"), (LPVOID *)&pVersionInfo, &nLength))
{
delete [] lpVersion;
return FALSE;
}
*lpMajorVersion = pVersionInfo->dwFileVersionMS;
*lpMinorVersion = pVersionInfo->dwFileVersionLS;
return TRUE;
}
You can then check the major/minor version numbers against ones you're expecting.
Can MapAndLoad from ImageHLP.DLL may help. It returns a LOADED_IMAGE structure.
Can you be more proactive and check the version of the QT binaries you need before you call LoadLibrary()? Then you can just warn your user they don't have the version your app needs, and maybe even provide a link to the install point for them.
You can also have windows check for this by using a manifest file. This file contains the information on the requirements on the used libraries' versions. More accurate and complete info is on the msdn site.
Take a look at the answer to this question about how to use LoadLibrary with a manifest file.
The Qt documentation briefly mentions the usage of a manifest file for VS2005; for earlier versions you would have to create it for your own.
I've added a new library to my application (multiple projects-DLLs) - SQLite, to perform some in memory caching. There is just one library/project that is affected by this change - Lib1.
A build goes through fine. All libraries are built successfully and no errors are reported, including a couple of Com Objects.
If I try to register the com objects, I get the The DLL could not be loaded. Check to make sure all required application runtime files and other dependent DLLs are available in the component DLL's directory or the system path. message. But all the libs are at the same place. And all are in the path. A copy of this project builds and registers fine (without the few changes made for SqlLite ofcourse). Dependency walker reports no issues
Oddly, if I try to register the DLL of the com object (using regsvr32) it works fine. Also, I have another library, which is dependant on Lib1 (not on SqlLite) which also cannot be loaded.
Any ideas?
Thanks,
A'z
You can use Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) set to filter process name regsvr32.exe in order to see all file and registry access.
Always use full path to your-com-dll when you issue regsvr32 commands, if you have the same dll somewhere else in path (for example c:\windows\system32) regsvr32 will use the other dll and not the one in your current directory.
Another trick would be to use "rundll32 your-com-dll,DllRegisterServer". In case of missing dlls it will tell which dll is missing instead of just saying that LoadLibrary failed.
Edit:
What do you mean by "If I try to register the com objects"? How are you doing this? I'm asking because you say that regsvr32 on the dll which actually implements these com object works fine.
Use the dependency walker tool to figure out what other dlls the COM server relies on. Then check the executable paths that is set in Visual Studio (Tools -> Options -> Projects -> Directories (I think)). Note that VS does not use the system PATH environment variable - it uses what is set in the options page so if the path to the dependencies is not listed there, the registration would fail, even though if you used regsvr32 from the command line it would succeed.
And so, the plot thickens!!!!
I've actually narrowed down the to the line of code that causes this linking problem.
In the modified library (LIB1) I've added a new class A1 which inherits from an existing class A.
When I change an existing class B which used to inherit from A to now inherit from A1 - this is when the problem is caused. Class B is in a lib3.
I've verified that just when I change the inheritance, only then the problem occurs!!!
I've used file-mon on regsvr32 when loading successfully and when failing. I stuggle to find the difference! Tomorrow morning I'll try Process Monitor and see if it helps.
Still desperate for help,
A'z
hmm... as Christian asks, how else are you attempting to register the objects if regsvr32.exe succeeds?
the rundll32.exe advice is also good. have you tried stepping through DllRegisterServer in a debugger to see precisely when it's failing? this sounds like a potential runtime failure if depends.exe isn't revealing anything.
btw, when i google for that exact error text i see: http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/402c1767-cf1d-42f0-aec9-e0169dbf1083/, but I assume you've probably already done this search and found it not helpful :)