One of my applications cannot load a system lib on the only machine. LoadLibraryEx returns 0 and the GetLastError returns 87 (The parameter is incorrect).
That can cause such error and how do I debug it?
Error appears only on a single machine which belongs to my client (server 2008R2). Libarary is located in system32 folder. Here is the code:
HMODULE lib = LoadLibraryEx(L"authui.dll", NULL,
LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_SEARCH_SYSTEM32);
if (lib == NULL)
{
DWORD err=GetLastError();
Log(L"error id: ", err);
throw;
}
I cannot reproduce the error on my copy of 2008R2 and have no idea what can cause the error. My app is written in VS2015 C++ (pure WinApi, no MFC or third party libs) and it is 64-bit.
Joel was right. The problem is in KB2533623 update which was not installed on the problem machine. I have changed my code to use absolute path as David Heffernan recommended and it works fine now.
Use the absolute path of authui.dll as the first parameter of LoadLibraryEx.
Related
I'm working a on project to use the SDK from https://github.com/hypersen/HPS3D_SDK
but I'm having troubles loading the DLL file, it returns me an error 126 for "libhps3d32.dll" and error 193 while using "libhps3d64.dll". I've seen many posts regarding these 2 errors but none of the solution so far works for me. Please help!
The dll file is the same location as the exe file. I've tried disabling my anti virus too, didn't help.
printf("Hello world!\n");
/*LoadLibrary */
HMODULE module = LoadLibraryA((LPCSTR)"C:\\Users\\xx\\Desktop\\xx\\libhps3d32.dll");
//printf("module loaded %d)",module);
if (module == NULL)
{
DWORD error_id = GetLastError();
printf("error load %d\n",error_id);
return;
}
EDIT: I was able to solve this by using dependency walker to trace the DLL file and its path. Found out that i was missing a few key dlls. Fixed after put them in place. Hope this works for everyone facing the same problems.
Another error at startup of my basic app which only tests my DLL (the core deliverable of my project) by calling its init method. I have analysed what happens using Process Monitor, and filtered according to process name, looking only for events related with my the main executable of my basic app.
What should I be looking for there ? I guess anything that says SUCCESS in the result column does not point to the problem - but what about the rest ? It seems to be looking for my DLL all over the world although it first tried in the current directory and found it there already ...
An excerpt here, saved from ProcMon in CSV format : http://pastebin.com/YHSeQUk0
As I said it tries to open my DLL in many places (following my PATH environment variable ?). When looking for it in the correct folder (which is the same as where the exe is located and running) it goes through a series of actions which mostly end up in SUCCESS (if not otherwise specified):
IRP_MJ_CREATE
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MJ_CREATE
FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION (result is : FILE LOCKED
WITH ONLY READERS)
FASTIO_ACQUIRE_FOR_CC_FLUSH
FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION (result is SUCCESS)
FASTIO_ACQUIRE_FOR_CC_FLUSH
It does all of this a second time later. To me this looks ok. No other DLL-related event show up.
There is this other event at the top :
RegOpenKey in HKLM\System\CurrentControlSet\Control\Srp\GP\DLL which first results in REPARSE and then in NAME NOT FOUND. But many things happen afterwards, this doesn't look like a blocking point - and anyhow no clue what this is about.
dumpbin /dependents ConsoleApplication1.exe yields the following :
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
uss_map_interface.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
KERNEL32.dll
The first one is my dll. If I remove it the message at startup turns into "uss_map_interface.dll is missing from your computer" - so I cannot believe this woukld be related to my DLL ... all the other I found in Windows/System32 or SysWOW64.
I am compiling both my DLL and the test basic app with MVS Express 2015 (v140) with x64 configs. The problem also appears if I change to x86 configs. The funny thing also is that if I compile my DLL with MinGW in a Qt project - it works fine. If that can provide a hint, here follow the dependencies of the Qz/MinGW-compiled version :
File Type: DLL
Image has the following dependencies:
libgcc_s_dw2-1.dll
KERNEL32.dll
msvcrt.dll
libstdc++-6.dll
Anyhow, thanks in advance !
I am using "LoadLibraryA()" for loading my dll. Here is the code for loading dll I used -
std::string m_sDllRegPath = "F:\\Releases\\SampleApp\\MyDll.dll";
m_hDll = LoadLibraryA(m_sDllRegPath.c_str());
But the problem is that value of m_hDll is always null, that it means it has failed to load the dll. A call to GetLastError returns 126.
But the same code works fine for 32 bit system. I don't know where is the problem.
Error code 126 is ERROR_MOD_NOT_FOUND:
The specified module could not be found.
If there really is a DLL with the file name that you provide, then the explanation is that one of the DLL's dependencies is missing. Almost invariably this is because the C++ runtime that is required by the DLL is not present. Check the requirements of the DLL, and make sure that all required dependencies are correctly installed.
I'm following this sites tutorial:
http://progtutorials.tripod.com/COM.htm
Preliminary evidence: Visual Studio 2010, Windows 7 64 bit.
and I'm coding the examples in section 3. (Implementing a server DLL). I've typed out the code exactly as shown and I'm getting a "Class not registered" exception when executing this code on line 12 of the code outlined in section 4.1 (where the tutorial shows you how to access the DLL and I have followed 3.1 to the letter):
hresult hr = CoGetClassObject(CLSID_Car, CLSCTX_SERVER, NULL, IID_IClassFactory, (void **) &pClassFactory);
I tried running:
regsvr32 xyz.dll
with xyz.dll being the path to my dll in order to register the DLL. This resulted in an error trying to find DLLRegisterServer:
I have already run
REGEDIT
HKEY_CLASSES_ROOT\CarDLL.Car\CLSID = {d969084c-b758-43ea-a218-a48763167abd}
HKEY_CLASSES_ROOT\CLSID\{d969084c-b758-43ea-a218-a48763167abd} = CarDLL.Car
HKEY_CLASSES_ROOT\CLSID\{d969084c-b758-43ea-a218-a48763167abd}\InProcServer32 = C:\Users\wiocl2\Documents\Visual Studio 2010\Projects\CarDLL\debug\CarDLL.dll
that I assumed put all the GUIDS I needed in the registry (The GUIDS were generated by me).
I'm assuming that a function is needed to be added to the class that allows it to be registered but I don't know how to do this and how to go about figuring it out. I'm kind of lost, as I haven't been working with COM for very long. If someone could give me a shove in the right direction that would be helpful.
Edit: Oh yes, I moved
#include // contains definition of DEFINE_GUID
to the iid.h file from iid.cpp, otherwise I was getting unresolved external errors on the build.
The most likely explanation: you are building your COM object as a 32-bit DLL, but the registration has been performed as a 64-bit DLL.
The treatment: open an admin privileged command window and navigate to the location of your DLL (C:\Users\wiocl2\Documents\Visual Studio 2010\Projects\CarDLL\debug). Once there, type:
c:\windows\sysWOW64\regedit <filename of .reg file whose contents are displayed above>
This will run the 32-bit version of REGEDIT, ensuring that the registry entries are created in the correct part of the hive. To verify this, you should see an entry for {d969084c-b758-43ea-a218-a48763167abd} in HKLM\Software\Wow6432Node\Classes\CLSID, not HKLM\Software\Classes\CLSID.
DllRegisterServer is a method you can implement in your COM server DLL, and is required if you want to use regsvr32 to perform the same operation you are currently using the .REG approach for. The same caveat applies: for a 32-bit DLL, you'll need to invoke c:\windows\sysWOW64\regsvr32.exe.
And Yes! COM is still mostly alive and well :) At least there is still standard support for it in VS 2012.
Hope that helps.
I write for a COM-Server (x86) a wrapper based on a DLL surrogate (x64) described like here to get access from a 64-bit-client.
I registered the COM-Server (x86) and the Proxy/Stub-DLL (x86) and they registered in the WOW6432-Nodes.
But when I call the instance with
IShellServerx86* pShellServer = NULL;
::CoCreateInstance(__uuidof(CShellServerx86), NULL, CLSCTX_LOCAL_SERVER |
CLSCTX_ACTIVATE_32_BIT_SERVER, __uuidof(IShellServerx86),
(void**)&pShellServer);
the dllhost.exe is started and I get back "Class not registered". When I analyse the dllhost.exe (x86-version!) with procmon I can see that the dllhost.exe tries to look up the paths in the 64bit-registry and not in the WOW6432-Nodes.
I tried to dupliate the registry entries into the 64-bit-paths but then I get back "%1 is not a WIN32 application".
How can I can COM to look up in the 32-bit paths? Is the flag "CLSCTX_ACTIVATE_32_BIT_SERVER" not enough?
Thanks for your help in advance.
Tobias
EDIT:
I found at MSDN this article that told that with Windows 7 registry reflection is disabled? It is said that all CLSIDs that contains a InprocServer32-Key are not reflected. But how then can I achieve reflection when I use System-Surrogation?