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 !
Related
On Linux and Mac, when using dlopen() to load a shared library that links to another library, if linking fails because of a missing symbol, you can get the name of the missing symbol with dlerror(). It says something like
dlopen failed: cannot locate symbol "foo"
On Windows, when using LoadLibrary() to load a DLL with a missing symbol, you can only get an error code from GetLastError() which for this type of issue will always be 127. How can I figure out which symbol is missing, or a more verbose error message from LoadLibrary() that explains why the function failed?
I figured out a way using the MSYS2 terminal. Other methods might work with GUI software.
A major caveat is that this can't be done in pure C/C++ and released for end users. It's for developers only, but it's better than nothing.
Install Debugging Tools for Windows by downloading the Windows SDK and unchecking everything except Debugging Tools.
I could be wrong, but it seems that installing this software installs a hook into the Windows kernel to allow LoadLibrary() to write verbose information to stderr.
Open the MSYS2 Mingw64 terminal as an administrator and run
'/c/Program Files (x86)/Windows Kits/10/Debuggers/x64/gflags.exe' -i main.exe +sls
This prints the following to the terminal to confirm that the registry has been changed.
Current Registry Settings for main.exe executable are: 00000002
sls - Show Loader Snaps
Use -sls instead of +sls if you need to undo, since I believe that the change takes place for all programs called main.exe in Windows globally, not just for your file.
Then running main.exe should print debug information to stderr, but since I'm debugging an -mwindows application, it's not working for me.
But for some reason, running the binary with MSYS2's gdb allows this debug information to be printed to stderr.
Install mingw-w64-x86_64-gdb with MSYS2 and run gdb ./main.exe and type run or r.
Search for a section similar to the following.
warning: 1ec8:43a0 # 764081125 - LdrpNameToOrdinal - WARNING: Procedure "foo" could not be located in DLL at base 0x000000006FC40000.
warning: 1ec8:43a0 # 764081125 - LdrpReportError - ERROR: Locating export "foo" for DLL "C:\whatever\plugin.dll" failed with status: 0xc0000139.
warning: 1ec8:43a0 # 764081125 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapModule raised exception 0xc0000139
Exception record: .exr 00000000050BE5F0
Context record: .cxr 00000000050BE100
warning: 1ec8:43a0 # 764081125 - LdrpProcessWork - ERROR: Unable to load DLL: "C:\whatever\plugin.dll", Parent Module: "(null)", Status: 0xc0000139
warning: 1ec8:43a0 # 764081171 - LdrpLoadDllInternal - RETURN: Status: 0xc0000139
warning: 1ec8:43a0 # 764081171 - LdrLoadDll - RETURN: Status: 0xc0000139
Great! It says Procedure "foo" could not be located in DLL so we have our missing symbol, just like in POSIX/UNIX's dlopen().
While the answer from Remy Lebeau is technically correct, determining the missing symbol from GetLastError() is still possible on a Windows platform. To understand what exactly is missing, understanding the terminology is critical.
Symbol:
When a DLL is compiled, it's functions are referenced by symbols.
These symbols directly relate to the functions name (the symbols are
represented by visible and readable strings), its return type, and
it's parameters. The symbols can actually be read directly through a
text editor although difficult to find in large DLLs.DLL Symbols - C++ Forum
To have a missing symbol implies that a function within cannot be found. If this error occurs prior to using GetProcAddress(), then it's possible that any number of functions cannot be loaded due to missing prerequisites. This means it is possible that a library that you are attempting to load also requires a library that the first cannot load. These levels of dependency may go on for an unknown number of layers, but the only answer that GetLastError() can determine is that there was a missing symbol. One such method is by using Dependency Walker to determine the missing library the first library requires. Once all required libraries are available and can be found by that library (which can be its own can of worms), that library can be loaded via LoadLibrary().
Hi, I try to embed mono in a c++ application on windows. I followed http://www.mono-project.com/docs/compiling-mono/windows/ and I have my headers, lib and dll built for win64.
I wrote a simple app that just calls
MonoDomain *domain;
domain = mono_jit_init("ConsoleApplication1.exe");
Everything builds and link find but when I run my program, I can break and step until the mono_jit_init call. Then the apps performs an exit1 and I can't see what's wrong.
I tried both release and debug.
Any ideas on how to find the issue? Properly embed mono?
Thanks, JNQ
Your application probably fails on loading Mono libraries.
You can use Process Monitor (https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) to find out what exactly fails for you:
Run Process Monitor
Set Process Monitor filter to "[Process Name] [is] [Your process name, e.g. ConsoleApplication1.exe] then [Include]"
Run you program and lookup for "CreateFile" operations with "NAME NOT FOUND" Result and see Path column to find out what file is missing
In my case it was a failure on loading mono mscorlib.dll from lib\mono\4.5\mscorlib.dll so copying the files from the Mono installation to the path pointed by Process Monitor has helped.
I have been working with WDK 10 and I have added rpcrt4.lib into the Linker. My driver has been successfully built. When I try to run the driver using command net start mydriver. I get system error 2 message. I tried using dependency walker but I don't see any dll file missing. When I remove the rpcrt4.lib from the Additional Dependencies, I am able to run the driver without any problem. But when I add rpcrt4.lib, it build successfully but on writing net start mydriver it gives system error 2. I need rpcrt4.lib as I am using a function UuidCreate.
I have been working on this issue for last 1 week, but did not find anything.
Thanks
Rpcrt4.dll is user mode dll and can not be used in kernel space. of course your driver is fail load with code STATUS_OBJECT_NAME_NOT_FOUND (which mapped to win32 error ERROR_FILE_NOT_FOUND (2) ) - system search registration of Rpcrt4.dll under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services and not found
for create uuid in kernel mode you need use ExUuidCreate
While deploying my application on iOS Simulator it works without any problems, but when I attached iPhone 5 on the Mac, deploying to that device results in following errors from Visual Studio's debug console:
Tool /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch execution started with arguments: --cache [... paths and arguments ...]
AOT Compilation exited with code 1, command:
MONO_PATH= [...path...]
The assembly mscorlib.dll was not found or could not be loaded.
1> It should have been installed in the `/Users/builder/data/lanes/3969/7beaef43/source/xamarin-macios/builds/install/cross64/lib/mono/4.5/mscorlib.dll' directory.
Xamarin.iOS.Common.targets(696,3): error : Could not AOT the assembly '/Users/blagoja/Library/Caches/Xamarin/mtbs/builds/MobApp.iOS/1be55aeb91c215df9342d3daa452982b/C:/Users/xxx/AppData/Local/Temp/vsF8C6.tmp/iPhone/Debug/mtouch-cache/64/Build/System.dll'
So fifth sentence (or sixth line) is saying that 'mscorlib.dll' could not be found at specified path, but from showed path where it should reside, on my mac i see only first directory 'Users'... nothing else.
So yeah, i belive i should put there the 'mscorlib.dll' but copy-paste is the right choice?
Also i managed to find multiple versions for mscorlib.dll into Developer/Frameworks/Mono.framework/Versions/{version}/lib/mono/{mono_versions}/mscordlib.dll. So maybe the configuration has path mismatches?
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.