You may have some advice on this page: http://www.echelon.com/support/kb/solution.asp?solutionID=668
This page is nearly exact describe my situation. However the guides there are not suitable.
As I can see, DEP are not able to shut down in W7 / WS2008.
The pathes to editbin (and thier way to be used) seem rewroten in VS2010
There are rumours about that NXCOMPAT has no effect anymore?
A little problem description,
An old DLL file from about year 2000 (probably C++ but can also be a VB6). It's a Interop COM DLL that has been used in several years in our old (VB6) environment. The DLL is attached in VS through the "Choose ToolBox Items / COM Components". Then added the dll to the project as Reference. I will state that this code runs from a Console Application (to avoid any IIS-related errors).When the code try to load an instance of the object, the error are shown.
Creating an instance of the COM component with CLSID {104B7F00-06EE-11CF-9AE0-0020AFD34749} from the IClassFactory failed due to the following error: 80040023.
What are your ideas here? How d开发者_StackOverflowid you solved your COM problem (in Windows 7 / Vista / Win Srv 2008?)?
tips :
- check runtine modules;
- use Depends to discover missing modules;
- use the tips in this link to interop 32/64 bit;
1) I don't seem to understand "As I can see, DEP are not able to shut down in W7 / WS2008." Yes, you can disable DEP in Win7. Please see here: http://www.fanhow.com/knowhow:Enable_or_Disable_DEP_in_Windows_7_27019737 2) editbin exists in VS2010 here (change this path according to your install drive): C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\editbin.exe. Open Visual Studio Command Prompt and you should just use it without knowing the path to it. 3) I don't think that's the case. Otherwise, this switch would be deprecated. The MSDN doc does not seem to suggest so: http://msdn.microsoft.com/en-us/library/ms235442(v=vs.100).aspx
Both the GUID and the error message suggest that you are dealing with a proprietary component. Thus, the documentation other than you've mentioned in the problem write up would not be helpful here. So, the other idea is to connect WinDbg to the process and see where the exception is really coming from. However, without the symbols / sources for the proprietary component identifying and fixing the problem seems like a non-trivial task.
精彩评论