I'm wanting to get some information from a dll a program I'm debugging is linked to:
So - I noticed that my debugger downloaded a pdb for a library where a crash happens, and I tried to run dia2dump on it:
dia2dump -all mfc90.i386.pdb\05089943A3B2462891FBF83E29A72618E\mfc90.i386.pd_
But dia2dump replies:
loadDataForExe failed - HRESULT = 806d0012
I don't know what that error message means... but I think (guess) it's because my msdia.dll is too old a version because I can dump the pdb's from older dll's that are at the 80's level; and I checked the dia.dll I installed and it's msdia80.dll, So -- I went and got msdia90.dll -- and I have now registered (regsvr32.exe msdia90.dll) and so I have installed both dia80.dll and dia90.dll. However, the dia2dump only co-creates the dia80.dll at run time .... and even if I unregister it, but leave dia90 registered -- dia2dump will then complain it can't find the dll at all. ( CoCreateInstance failed - HRESULT = 80040154 )
I'm not sure if this is because I am on a 32 bit machine, or because I am compiling under VS2008... or I registered the wrong dia90.dll somehow... or what? How do I figure it out?
This is what I've tried so far:
I modified dia2dump.cpp to load the dll based on a the __uuid() of a forward reference to the class DiaSource; I hoped that the __uuid() would be able to find the active version of the class in the registry and supply the correct number, but VS2008 apparently doesn't work that way -- it computes the __uuidof() in some other fashion ... because even with diaguid.Lib deleted, and CLSID_DiaSource becoming undefined (I verified it can't find it.) using __uuidof(DiaSource) still caused it to find the CLSID for msdia80.dll -- not 90.
typedef class DiaSource;
hr = CoCreateInstance(__uuidof(DiaSource),//CLSID_DiaSource,
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(IDiaDataSource),
(void **) ppSource);
So, why is this not also linking to the CLSID for msdia90.dll ?
I don't have the diaguid.Lib for version 90 -- just the dll. But I do know, in the registry that there are two uuid's / CLSID's -- one for each version of the dll.
HKEY_CLASSES_ROOT/CLSID/4C41678E-887B-4365-A09E-925D28DB33C2 # msdia90.dll
HKEY_CLASSES_ROOT/CLSID/BCE36434-2C24-499E-BF49-8BD99B0EEB68 # msdia80.dll
Although, in the latest MSDN page at this time (2013), the name of the variable is still CLSID_DiaSource , suggesting the class is named the same in the new dll... So I don't know why there are two different CLSID's for the dll's...
http://msdn.microsoft.com/en-us/library/hd8h6f46%28v=vs.120%29.aspx
EDIT:
I got it to link (CoCreate), I think, by doing this trick as a work-around, but the original error still happens when I run it with version 90 -- so my guess was wrong...
class __declspec(uuid("4C41678E-887B-4365-A09E-925D28DB33C2")) msdia90;
hr = CoCreateInstance(__uuidof( msdia90 ),
So, I'm totally lost. Why cant dia2dump.exe work on a downloaded mfc90.pdb file?
Related
While trying to run opencv sample matlab call, I am getting an error
Invalid MEX-file 'mypath\displayImage.mexw64': mypath\displayImage.mexw64 is not a valid Win32 application.
There are no errors while compiling. Also there are no errors while compiling and running simple helloworld sample.
What can be a reason for this? Why it expects win32 when even filename says 64?
Matlab is 2013a, VS is 2012, both are 64bit.
UPDATE
I found this "solution" of year 2009 saying that any of called DLLs should be 64 bit.
Is this
(1) true nowadays, and
(2) possible in practice?
How to check if some called library is 32bit?
Ok my PATH was pointing to %OPENCV_DIR%\build\x86\vc11\bin and this was overriding any LIB settings.
This was at runtime.
I.e. when I fixed PATH value, program started to run even without recompiling.
We are working on a ATL COM DLL migration project migrating code from VC++6 to VC++10 and the object_map failed to load up.
It is basically same as problem encountered by
swapnil_shinde here
The DLL shown as registered successfully, and shown in typelib, but not in the CLSID.
Existing code works fine with VC6 on Window XP but not with VC10 on Window 7.
The registration is fair standard using DLLRegisterServer of the atlbase.h in VC10.
Any idea any one?
We think the stackoverflow community is more active and variety of knowledge.
Any additional information we missed out, please ask and we will provide as well.
Thanks a lot.
Edit:
I'm running as an Administrator, 32 bit app testing on 32 bit window 7.
I have searched the entire registry for the CLSID can still cannot find it.
Try registering your object using the OBJECT_ENTRY_AUTO macro instead. In the header of each object put an reference to the entry after the class declaration, e.g.:
class CMyObject { ... class decl ... };
OBJECT_ENTRY_AUTO(__uuidof(MyObject), CMyObject)
If that doesn't work you'll need to run it through the debugger (using regsvr32 as the EXE) and watch what happens in DllRegisterServer.
I'm running a 32 bit ver of win7 in a vm. I am trying to reference 5 com dlls (VB6) in my .net project. These dlls (and their dependencies) are registered ok since I can use them natively as they form a part of another app and that app is working fine.
I try to set a reference to any of them directly in vs and I get the error message - Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
However, if I set a reference to another com component (which I don't want to reference but which in turn does reference these libs) I find that the references to these com dlls (which I do want to reference) gets set correctly in vs. I then just need to remove the ref to the unwanted dll and everything seems to be good to go.
If I look at the GUID and version details of one of the successfully referenced component, they appear to be the same as the GUID and version that appears in the caption of the error form, when I unsuccessfully try and set a reference to the same component directly.
BTW I have tried repairing the VS installation to no avail
I was wondering if someone could explain what I am doing wrong.
EDIT: Follow-up following Hans suggestion
So I ran
tlbimp mylib.dll
and it returned a TI1006 error - Output would overwrite the input file. So following suggestions found, I then issued
tlbimp mylib.dll /OUT:interop.mylib.dll
and this then returned the error
TlbImp : warning TI3011 : Type library importer has encountered an interface not derived from IUnknown: '_HiddenInterface'. The interface is skipped.
TlbImp : error TI1033 : Cannot find type 'ADODB._Recordset_Deprecated' in 'ADODB, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. There could be a mismatch between the referenced assembly and the type library.
But I'm not sure if this is a red herring since this lib could be referenced when successfully referencing the different higher level dll. I have tried with a dll which doesn't reference ADODB and that seems to work using tlbimp. So, e.g.
tlbimp myNONADODBlib.dll /OUT:interop.myNONADODBlib.dll
works from the commandline. However
tlbimp myNONADODBlib.dll
still generates the error TI1006 - output file will overwrite input file, and I cannot reference this into my .net project
EDIT:
There seems to be a problem with ADO and Win7 SP1. http://support.microsoft.com/kb/2517589 which would account for the deprecated error message (TI1033) I was getting, but not why VS was failing to create a CCW for the dll I can manually create a CCW via tlbimp.
EDIT (12/03/28 10:40):
So I have rebuilt the com dll with the suggested tlb. I can now successfully run
tlbimp mylib.dll
without getting any error messages and it appears to complete successfully. However, when I try and add a reference to that dll in VS, I still get the same original error message ( Library not registered (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))). I have checked the registry and the registration looks ok i.e. it is pointing to the correct path - I'm wondering if it is a permissions-type issue - but I am running vs as admin.
EDIT (12/03/28 10:15):
So I ended up creating a new completely new vm with the same environment - and it worked ok. So I've no idea what is going on other than some registry corruption perhaps!
Many thx
Simon.
You need to use REGTLIB.exe to register the type library of the DLLs.
Type library registration is separate from component registration - the type library supports the introspection/type explorer functionality, and isn't usually required for running a precompiled application, though it may be required for compilation.
I tried to make a simple demo program that use zlib to compress & decompress files, but when I link the file, Visual Studio 2010 linker gave me this error:
Error 2 error LNK1313: ijw/native module detected; cannot link with pure modules
When I tried to change /clr:pure to just /clr. the program compiles and runs, but gave me a run time error:
"The application was unable to start correctly(0xc000007b). Click OK to close the application."
This is my code so far for just getting zlib version in balloon tip:
String^ info = gcnew String(reinterpret_cast<const char*>(zlibVersion()));
notify->ShowBalloonTip(20000, "Zlib Version", info, ToolTipIcon::Info );
Can you help me figure out what happened to zlib and what is that error. Thanks
If you're targeting the CLR I strongly recommend using a native (to the CLR) Zipping/Zlib library, such as DotNetZip, rather than trying to shoehorn a native library into doing what you want.
I'm not a C++/CLI expert, so this might be entirely wrong, but I believe
String^ info = gcnew String(reinterpret_cast<const char*>(zlibVersion()));
results in undefined behavior. The reason is that the System::String constructor expects an array of System::Char objects, not C++'s char data type. System::Char is two bytes wide, char is a single byte wide (System::String supports Unicode; zlib does not). (In any case, reinterpret_cast is a major red flag -- why are you using that cast here?)
Also, error 0x7B is
The filename, directory name, or volume label syntax is incorrect.
(The 0xC is there probably because it's an NTSTATUS code) Make sure that if you're using the dynamically linked version of Zlib that the DLL is available for your program to open somewhere.
I'm converting a Carbon app to a Cocoa app and I can't find the Cocoa equivalent for:
UpdateSystemActivity(UsrActivity);
Any Mac people out there care to point me in the right direction? Thanks.
UPDATE: I'm building 64bit. Building 32bit works fine, but I get symbol not declared in this scope errors for UpdateSystemActivity (and others) when I build for 64bit.
UPDATE2: I'm importing the following:
#import <Cocoa/Cocoa.h>
#import <Carbon/Carbon.h>
#import <OpenGL/CGLMacro.h>
Is there some other thing I need to import when building 64bit?
UPDATE3: Adding #import <CoreServices/CoreServices.h> did not help. I still get compiler errors telling me UpdateSystemActivity and UsrActivity was not declared in this scope.
UPDATE4: Okay, file not found on OSServices/Power.h. I'm building against the 10.5 SDK and a quick search shows:
$ pwd
/Developer/SDKs
$ find . -name Power.h
./MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/OSServices/Power.h
./MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/Power.h
./MacOSX10.3.9.sdk/Developer/Headers/FlatCarbon/Power.h
./MacOSX10.3.9.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Headers/Power.h
./MacOSX10.4u.sdk/Developer/Headers/CFMCarbon/OSServices/Power.h
./MacOSX10.4u.sdk/Developer/Headers/CFMCarbon/Power.h
./MacOSX10.4u.sdk/Developer/Headers/FlatCarbon/Power.h
./MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Headers/Power.h
./MacOSX10.5.sdk/Developer/Headers/FlatCarbon/Power.h
./MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Headers/Power.h
Yet I get:
Mac.mm:6:29: error: OSServices/Power.h: No such file or directory
Mac.mm:6:29: error: OSServices/Power.h: No such file or directory
In OS X 10.6 and later IOKit can be used to disable sleep. Create an IOPMAssertion when you want to disable sleep and destroy it when you want to allow sleep again.
#import <IOKit/pwr_mgt/IOPMLib.h>
// kIOPMAssertionTypeNoDisplaySleep prevents display sleep,
// kIOPMAssertionTypeNoIdleSleep prevents idle sleep
// reasonForActivity is a descriptive string why sleep is disabled
CFStringRef* reasonForActivity= CFSTR("Describe Activity Type");
IOPMAssertionID assertionID;
IOReturn success = IOPMAssertionCreateWithName(kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, reasonForActivity, &assertionID);
if (success == kIOReturnSuccess)
{
//Add the work you need to do without the system sleeping here.
success = IOPMAssertionRelease(assertionID);
//The system will be able to sleep again.
}
More information: https://developer.apple.com/library/mac/qa/qa1340/_index.html
The issue here appears to be the line in OSServices.h that excludes Power.h if __LP64__ is defined. When building 64 bit on 10.5 UpdateSystemActivity is indeed undefined.
The good news is that the symbol does actually exist in CoreServices.framework. There are two ways to get access to it.
Forward declare it: extern "C" OSErr UpdateSystemActivity(UInt8);
Explicitly include Power.h, which you tried. The issue with your attempt is that OSServices/ doesn't find it's way into the search path. You can include it like so: #import </Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/Power.h>
I don't have a copy of SnowLeopard handy, but the next thing to do would be to check if it's fixed there. If it isn't, file a RADAR as this is clearly an SDK bug.
You should still be able to call UpdateSystemActivity from within your Cocoa app -- it has not been marked deprecated.
The documentation for the API specifies importing CoreServices/CoreServices.h to get the API -- however hunting through the headers (notably in OSServices/OSServices.h) shows that the file is omitted in a 64bit environment. Nevertheless, there are sections of Power.h (where UpdateSystemActivity is defined) that are turned off for 64bits, and UpdateSystemActivity is not one of them.
In light of that, try to #import <OSServices/Power.h> directly and see if that works. (You'll have to include the CoreServices framework in your project for the header to be found as well.)