-
December 14th, 2018, 04:07 AM
#1
Dcom Interface No such interface supported after migration to X64
we changed our Software from X86 to X64 since there is a Problem with the dcom Interface. We get the following error
018-12-14 06:26:23.999 [002E8,0668] DEVELOPER TRACE: TComPtr<{2DF6EF8A-3EE8-11D1-BF07-008029E20A31}="">::coCreateInstance(clsid={2DF6EF8B-3EE8-11D1-BF07-008029E20A31}="NmsTaskManager.JobManager",user=tkocher) failed with rc=0x80004002 No such interface supported
we created the Interface as we did this for X86 by setting the registry keys
Code:
static void doSetDcomClientInterface( const CString& serverName, const CString& aName, const CString& cName, const CString& clsid, const CString& appid ){
out("... doSetDcomClientInterface serverName " + serverName + " aName " + aName + "cName " + cName + " clsid " + clsid + " appid " + appid + " ... ");
doDeleteKey( "HKCR\\CLSID\"+clsid );
doDeleteKey( "HKCR\\AppID\"+appid );
doSetKey( "HKCR\"+cName , "" , cName );
doSetKey( "HKCR\"+cName+"\\CLSID" , "" , clsid );
doSetKey( "HKCR\\AppID\"+appid , "" , aName );
doSetKey( "HKCR\\AppID\"+appid , "RemoteServerName" , serverName );
doSetKey( "HKCR\\CLSID\"+clsid , "" , cName );
doSetKey( "HKCR\\CLSID\"+clsid , "AppID" , appid );
out("... doSetDcomClientInterface serverName " + serverName + " aName " + aName + "cName " + cName + " clsid " + clsid + " appid " + appid + " done ... ");
}
doSetKey is setting the registry Key in the windows registry
the parameters for the the NmsTaskManager.JobManager are
serverName:PC1087
aName:Nms Task Manager
cName:NmsTaskManager.JobManager
clsid:{2DF6EF8B-3EE8-11D1-BF07-008029E20A31}
appid:{2DF6EF81-3EE8-11D1-BF07-008029E20A31}
which are the same which worked on X86
must i set the dcom Interace for X64 differently?
does anybody knows why i does no more works ?
Last edited by 2kaud; January 18th, 2019 at 07:59 AM.
Reason: Added code tags
-
December 22nd, 2018, 12:13 AM
#2
Re: Dcom Interface No such interface supported after migration to X64
It looks like you do COM registration in a different environment. You need to understand the effect of WOW64 and bitness of your binary modules.
32-bit modules run in separate Windows subsystem with a separate registry.
The more beautiful thing with this is that you are not able to load your 32-bit COM dll into 64-bit process.
Best regards,
Igor
-
January 18th, 2019, 06:18 AM
#3
Re: Dcom Interface No such interface supported after migration to X64
why do you think or know that the COM registration rons in the 32 Bit environment? i switched all the projects and exes ( including the one which registers ) to 64 Bit . An some dcom Registration do work
-
January 20th, 2019, 09:17 PM
#4
Re: Dcom Interface No such interface supported after migration to X64
Originally Posted by ThomasAndreas Kocher
An some dcom Registration do work
What are the differences in DCOM servers that work compared to those that don't work? Are the non-working services registered differently? Do they have old 32-bit registry registration entries that conflict with the 64-bit entries (i.e. did you attempt to register them as 32-bit before recompiling and register them as 64-bit)? Do the 64-bit services that don't work still have some 32-bit dependencies (either COM or otherwise)?
-
January 21st, 2019, 01:48 AM
#5
Re: Dcom Interface No such interface supported after migration to X64
What are the differences in DCOM servers that work compared to those that don't work?
I cold not fint
here some Information on the working one
The IDL File
Code:
Code:
// NmsTaskDbSv.idl
import "oaidl.idl";
import "ocidl.idl";
[
object,
uuid(9B870525-DB58-11D1-B532-00A024D2B68A),
dual,
helpstring("INmsDbData Interface"),
pointer_default(unique)
]
interface INmsDbData : IDispatch
{
[id(1)] HRESULT Do ( [in] long id, [in] BSTR version, [in] BSTR sender, [in] BSTR login, [in] BSTR selection, [out, retval] long* retval);
[id(2)] HRESULT Request ( [in] long id, [in] BSTR version, [in] BSTR sender, [in] BSTR login, [in] BSTR selection, [in, out] BSTR* data, [out, retval] long* retval );
[id(3)] HRESULT OnTicket ( [in] BSTR dialNumber, [in] BSTR recordType, [in] BSTR calculatedCharge, [in] BSTR currency, [in] BSTR chargePulseInfo, [in] BSTR timeStamp, [in] BSTR duration, [in] BSTR digits, [out, retval] long* retval );
[id(4)] HRESULT sendCmd ( [in] BSTR cmd, [in, out] BSTR* result );
[id(5)] HRESULT sendCmdBinary ( [in] BSTR clientName, [in] BSTR userName, [in] BSTR cmd, [in, out] BSTR* result );
};
[
uuid(A2B28E54-D524-11D1-B51B-00A024D2B68A),
version(1.0),
helpstring("NmsTaskDbSv 1.0 Type Library")
]
library NmsTaskDbSvLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[
uuid(A2B28E53-D524-11D1-B51B-00A024D2B68A),
helpstring("NmsTaskDbSv.NmsDbData")
]
coclass NmsDbData
{
[default] interface INmsDbData;
};
};
and the RGS File
Code:
Code:
HKCR
{
NmsTaskDbSv.NmsDbData = s 'NmsTaskDbSv.NmsDbData'
{
CLSID = s '{A2B28E53-D524-11D1-B51B-00A024D2B68A}'
}
NoRemove CLSID
{
ForceRemove {A2B28E53-D524-11D1-B51B-00A024D2B68A} = s 'NmsTaskDbSv.NmsDbData'
{
ProgID = s 'NmsTaskDbSv.NmsDbData'
VersionIndependentProgID = s 'NmsTaskDbSv.NmsDbData'
ForceRemove 'Programmable'
LocalServer32 = s '%MODULE%'
val AppID = s '{D2FF4B01-F303-11D2-8352-00A02479FB54}'
}
}
}
the same Info about the not working one
IDL
Code:
Code:
// NmsTaskManager.idl
import "ITask.idl";
[
uuid(2DF6EF8A-3EE8-11D1-BF07-008029E20A31),
helpstring("IJobManager Interface"),
pointer_default(unique)
]
interface IJobManager : IUnknown {
//HRESULT sendCmd ( [in] BSTR cmd, [out] BSTR* result );
HRESULT sendCmdBinary ( [in] BSTR clientName, [in] BSTR userName, [in] BSTR cmd, [in, out] BSTR* result );
};
// Class library
[
uuid(2DF6EF80-3EE8-11D1-BF07-008029E20A31),
version(1.0),
helpstring("NmsTaskManager 1.0 Type Library")
]
library NmsTaskManagerLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[
uuid(2DF6EF8B-3EE8-11D1-BF07-008029E20A31),
helpstring("NmsTaskManager.JobManager")
]
coclass JobManager
{
[default] interface IJobManager;
};
};
and the rGS
Code:
Code:
HKCR
{
NmsTaskManager.JobManager = s 'NmsTaskManager.JobManager'
{
CLSID = s '{2DF6EF8B-3EE8-11D1-BF07-008029E20A31}'
}
NoRemove CLSID
{
ForceRemove {2DF6EF8B-3EE8-11D1-BF07-008029E20A31} = s 'NmsTaskManager.JobManager'
{
ProgID = s 'NmsTaskManager.JobManager'
VersionIndependentProgID = s 'NmsTaskManager.JobManager'
ForceRemove 'Programmable'
LocalServer32 = s '%MODULE%'
val AppID = s '{2DF6EF81-3EE8-11D1-BF07-008029E20A31}'
}
}
}
The Code for creating the dcomInterfac is the following as allready posted
Code:
Code:
static void doSetDcomClientInterface( const CString& serverName, const CString& aName, const CString& cName, const CString& clsid, const CString& appid ){
out("... doSetDcomClientInterface serverName:" + serverName + " aName:" + aName + " cName:" + cName + " clsid:" + clsid + " appid:" + appid + " ... ");
doDeleteKey( "HKCR\\CLSID"+clsid );
doDeleteKey( "HKCR\\AppID"+appid );
doSetKey( "HKCR"+cName , "" , cName );
doSetKey( "HKCR"+cName+"\\CLSID" , "" , clsid );
doSetKey( "HKCR\\AppID"+appid , "" , aName );
doSetKey( "HKCR\\AppID"+appid , "RemoteServerName" , serverName );
doSetKey( "HKCR\\CLSID"+clsid , "" , cName );
doSetKey( "HKCR\\CLSID"+clsid , "AppID" , appid );
out("... doSetDcomClientInterface serverName:" + serverName + " aName:" + aName + " cName:" + cName + " clsid:" + clsid + " appid:" + appid + " done ... ");
}
So he just creates the necessary Registry entries ( doSetKey) writes to the windows registry. Where can the problem with the dcom Interface
Are the non-working services registered differently?
no they both are registertd with /RegServer but the one which does not work is a service
Do they have old 32-bit registry registration entries that conflict with the 64-bit entries (i.e. did you attempt to register them as 32-bit before recompiling and register them as 64-bit)?
This may be i did not chamged the clsid and the apipid with the migration to 64 Bit Bit even when i tried to chamge them i had the same error
Do the 64-bit services that don't work still have some 32-bit dependencies (either COM or otherwise)?
not more than the working one But the depency wlker fond some X86 for both of them
IERTUTIL.DLL and ODBC32.DLL are both X86 but both need them
Last edited by 2kaud; January 21st, 2019 at 05:05 AM.
Reason: Added code tags
-
January 21st, 2019, 03:48 AM
#6
Re: Dcom Interface No such interface supported after migration to X64
Hi Thomas,
Please, edit your post adding CODE tags around the code snippets. Otherwise your code is very hard to read/understand!
See the Announcement: Before you post....
Victor Nijegorodov
-
January 21st, 2019, 03:52 AM
#7
Re: Dcom Interface No such interface supported after migration to X64
no they both are registertd with /RegServer but the one which does not work is a service
Does the service start up? If so, does it start up as a 64-bit process or 32-bit?
-
January 21st, 2019, 06:05 AM
#8
Re: Dcom Interface No such interface supported after migration to X64
Yes the service can be started and he is 64 Bit ( checked with dumpbin )
-
January 21st, 2019, 06:17 AM
#9
Re: Dcom Interface No such interface supported after migration to X64
What account does this service run under? Does the account have the permission to access the resources it needs?
-
January 21st, 2019, 07:47 AM
#10
Re: Dcom Interface No such interface supported after migration to X64
This cant be the Problem the servuces runs under an account which is member auf The Admintrators gruop and the "Distributed Com Users" Group
-
January 21st, 2019, 01:33 PM
#11
Re: Dcom Interface No such interface supported after migration to X64
Ok, just something else to rule out. I have done quite a bit of DCOM programming but it was years ago and all 32-bit. To me, the fundemental issue I see is you are attempting to execute code from 32-bit code from your 64-bit process. AFAIK, this isn't supported.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|