C++ Loadlibrary() error 3765269347

Question

I have got this Loadlibraty() error 3765269347 bothering me. I am implementing a C++ console application, built as x64, to load a x64 native C++ dll. Following is the code in the C++ console application to load the dll:

  bool InitDll()
{
    HINSTANCE hInst = LoadLibrary(_T("C:\\TIS_Nick\\Hardware\\Devices\\ThorDetectorSwitch\\TDSTest\\TDSTest\\Debug\\Modules_Native\\ThorDetectorSwitch.dll"));
    if( hInst != NULL )
    {
        FreeLibrary( hInst ); 
        return true;
    }
    else
    {
        DWORD err = GetLastError();
        return false;
    }
}

I got err is 3765269347, which I think means C++ cannot handle this error. I am sure my path to load the dll is correct.

I also use Monitor Process to trace what the dll and functions get called. and here is the information I think relevant.

11:08:07.3196483 AM TDSTest.exe 1604    QueryNameInformationFile    C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\x64\Debug\TDSTest.exe   SUCCESS Name: \TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\x64\Debug\TDSTest.exe
11:08:08.5720585 AM TDSTest.exe 1604    CreateFile  C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
11:08:08.5721041 AM TDSTest.exe 1604    QueryBasicInformationFile   C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS CreationTime: 6/11/2013 6:30:08 PM, LastAccessTime: 6/11/2013 6:30:08 PM, LastWriteTime: 6/12/2013 11:00:28 AM, ChangeTime: 6/12/2013 11:05:51 AM, FileAttributes: A
11:08:08.5721293 AM TDSTest.exe 1604    CloseFile   C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS 
11:08:08.5722797 AM TDSTest.exe 1604    CreateFile  C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
11:08:08.5723228 AM TDSTest.exe 1604    CreateFileMapping   C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: 
11:08:08.5724896 AM TDSTest.exe 1604    CreateFileMapping   C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS SyncType: SyncTypeOther
11:08:08.5725861 AM TDSTest.exe 1604    Load Image  C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS Image Base: 0x7fef7830000, Image Size: 0x6d000
11:08:08.5726385 AM TDSTest.exe 1604    QueryNameInformationFile    C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS Name: \TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll
11:08:08.5728910 AM TDSTest.exe 1604    CreateFile  C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
11:08:08.5912215 AM TDSTest.exe 1604    CloseFile   C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll SUCCESS

I aplogize that looks a little messy, I was trying to post a picture here, but it turns out I don't have enough reputation to do so. Any suggestion is appreciated.

Update I have traced down to the constructor in ThorDetectorSwitch.dll, which looks like following:

ThorDetectorSwitch::ThorDetectorSwitch() : _mcSwitch(__uuidof(MCLControlClass))
{
    _A  = WstringToBSTR(L"A"); 
    _B  = WstringToBSTR(L"B");
    _C  = WstringToBSTR(L"C");
    _D  = WstringToBSTR(L"D");

    _deviceDetected = FALSE;
}

I set the break point at the first parenthesis, but it never gets into the function. Instead, it jumps to the exceptions. I suppose something wrong with the MCLControlClass, or_mcSwitch?

Don't assume anything about the error, rather look at the documentation. — Luchian Grigore, Jun 12 '13 at 15:28
Getting an undefined error (that code) usually means the library threw an un handled exception. Don't you get anything in the output window when debugging? (assuming visual studio here) — Jcl, Jun 12 '13 at 15:30
Are you 100% sure your path is correct? The path you show in your code to load the .dll file is `C:\TDSTest\Debug\ThorDetectorSwitch.dll`, whereas the path shown in the log you sent to the .dll file is `C:\TIS_Nick\Hardware\Devices\ThorDetectorSwitch\TDSTest\TDSTest\Debug\Modules_Native\ThorDetectorSwitch.dll`. — aardvarkk, Jun 12 '13 at 15:30
@chris The DWORD err = GetLastError(); returns the err, which is 3765269347 as I observed. — Nick X Tsui, Jun 12 '13 at 15:30
@aardvarkk, Sorry, my bad, but the path is right. I have edited it. — Nick X Tsui, Jun 12 '13 at 15:31
This looks very similar to your problem: http://stackoverflow.com/questions/4428824/loadlibrary-problem-on-win7-64-bit — Sebastian Redl, Jun 12 '13 at 15:33
@Jcl Yes, I got this: exception at 0x000007fefdb59e5d in TDSTest.exe: Microsoft C++ exception: _com_error at memory location 0x0028edb0..; But I have no idea what that means. I know that I in the ThorDetectorSwitch.dll, there is another dll, which is reegistered as a COM coponent using "regasm", gets called. — Nick X Tsui, Jun 12 '13 at 15:35
Start in debug mode and set your debugger to break on first-chance C++ exceptions. Then observe where it fails. The exception _com_error is part of a small COM helper library provided by VC++, so something is throwing that. — Sebastian Redl, Jun 12 '13 at 15:38
@SebastianRedl: I was about to add a comment that searching for the hex value of the error code (0xE06D7363) shows the same thing you'v elinked to - looks like the DLL is likely throwing an exception but nothing is catching it. — icabod, Jun 12 '13 at 15:38
@NickXTsui sounds like `DllMain` on the DLL is throwing an unhandled exception. If the DLL is your own (or have the source code), you can probably debug it... if it's not, then tough luck. The problem is not in the code loading the library, but in whatever the library is doing. — Jcl, Jun 12 '13 at 15:39
(you can probably debug it in assembler if you don't have the source, but that'd be a royal pain in the b*tt... ) — Jcl, Jun 12 '13 at 15:40
@SebastianRedl How do I debug my fisrt-chance C++ exception? Do I set a break point some where in dllmain? I did, but it was not hit. — Nick X Tsui, Jun 12 '13 at 15:44
@Jcl I think I have the source code for the ThorDetectorSwitch.dll, so how do I debug it? The dllmain.cpp is an independent file, but is in the save project as ThoDetectorSwitch.cpp. — Nick X Tsui, Jun 12 '13 at 15:46
@NickXTsui Press Ctrl+Alt+E, it brings up the exception settings. Find "C++ exceptions" there and check both boxes. Then start the debugging run. It should break automatically where it attempts to throw the exception - you probably need to look at the call stack to find out where you really are, because it breaks in the internals. Make sure you have debug symbols for the Windows libraries to get proper call stacks. — Sebastian Redl, Jun 12 '13 at 15:49
Make Visual Studio break on thrown exceptions (Debug + Exceptions, Thrown, IIRC)... it should ask for the source file when the exception is actually thrown inside the DLL if it's compiled with debug symbols: point it to the .cpp and you can actually step there to see what's going on. It's hard to say without seeing the whole scene — Jcl, Jun 12 '13 at 15:49
@SebastianRedl and Jcl OK, I got the exceptions happening in some comip.h file, the arrow stops at explicit _com_ptr_t(const CLSID& clsid, IUnknown* pOuter = NULL, DWORD dwClsContext = CLSCTX_ALL) : m_pInterface(NULL), and the _com_issue_error(hr); says "CoInitialize has not been called" for hr — Nick X Tsui, Jun 12 '13 at 16:00
@NickXTsui : Not a solution if you don't know what it means, but call `CoInitialize(NULL)` (in `objbase.h`) before calling `LoadLibrary`. That should initialize COM. The problems with COM are way beyond the scope of this question, but that should at least make it not throw that exception. `CoInitialize` can only be called once per application. — Jcl, Jun 12 '13 at 16:21
@Jcl I have traced down to the constructor of the ThorDetectorSwitch.dll. See my update in original post. Thanks a lot. — Nick X Tsui, Jun 12 '13 at 17:35
I guess I should stop here because it seems my direction shifted to another path. So I guess I will close my question here, and take Passant's qnaswer.Sorry to Martini because I feel Passant's answer is more detailed and makes more sense to me. I also want to thank everybody especially here for your generasoty of sharing opinions. — Nick X Tsui, Jun 12 '13 at 18:02

Hans Passant · Accepted Answer · 2019-05-22T08:12:38.230

I got err is 3765269347

The generic strategy with large error number values like this is to convert them to hex. 3765269347 == 0xE06D7363. That's a magic number, googles well too. One strategy used by Microsoft programmers is to make the last 3 bytes of an exception code ASCII codes. 6D7363 == "msc". Not enough room to add ++ :)

The diagnostic is that the DllMain() function inside the DLL died due to an unhandled C++ exception. That happens of course.

The way to debug it is to force the debugger to stop when the exception is thrown, before the OS loader can catch it and turn it into a failure code. Within Visual Studio, use Debug > Exceptions, tick the Thrown checkbox for C++ exceptions.

Making sense of what you see when the debugger stops depends a great deal on whether you have a good PDB file for the DLL and whether you have source code. Source is of course typically required to fix a problem. If you don't have access to anything like this then you do need help from the programmer that wrote that DLL. Send him a small repro project that reproduces the crash.

I don't quite understand the debugging part. "Force the debugger to stop when the exception is thrown", how do I do that? set a break point at Loadlibrary(), then set another break point some where in dllmain.cpp? — Nick X Tsui, Jun 12 '13 at 15:52
Look at the menu at the top of the window. Click Debug. Click Exceptions. A dialog opens. Tick the Thrown checkbox. — Hans Passant, Jun 12 '13 at 16:21
I see. Now I can step in my dll, so I guess I should start from there. Thanks a lot. — Nick X Tsui, Jun 12 '13 at 18:03

score 4 · Answer 2 · answered Jun 12 '13 at 15:34

4

This is a special execption. Please read this from MS: Decoding the parameters of a thrown C++ exception (0xE06D7363)

answered Jun 12 '13 at 15:34

Michael Martini

51
2

C++ Loadlibrary() error 3765269347

2 Answers2

Linked