"Access Violation Error" Using Custom COM [modified]
-
hi everyone, i created a custom COM component (.exe) which is used by another .dll. i compiled the both components fine, including the code snippet below; but i get a runtime access violation error on line of exe->Dummy() after CoCreateInstance returns S_OK. it gives different addresses for each different method of the .exe component i try. this code is inside a method of the .dll component
HRESULT hr = 0; ATLVERIFY(SUCCEEDED(CoInitialize(NULL))); ATL::CComPtr exe; hr = exe.CoCreateInstance(CLSID_Something,NULL,CLSCTX_LOCAL_SERVER); // call out for .exe component ATLASSERT(SUCCEEDED(hr) && exe != NULL); ATLVERIFY(SUCCEEDED(exe->Dummy())); // access violation here exe.Release(); // doesn't make it to here anywayMy .exe component is non-attributed just like the .dll (not sure if it makes any difference), i have built and registered the proxy-stub class fine, and also my .exe file is registered with "exe /RegServer". i think there is one more thing to be done but just couldn't find out what. if it were the registry script or something, i shouldn't be getting an instance of the .exe component. any ideas ? please have some !! -- modified at 14:18 Thursday 22nd March, 2007 edit: i converted the .exe interface to be non-dual (it was a dual interface before) and this time exe->Dummy() returns "A null reference pointer was passed to the stub." -
hi everyone, i created a custom COM component (.exe) which is used by another .dll. i compiled the both components fine, including the code snippet below; but i get a runtime access violation error on line of exe->Dummy() after CoCreateInstance returns S_OK. it gives different addresses for each different method of the .exe component i try. this code is inside a method of the .dll component
HRESULT hr = 0; ATLVERIFY(SUCCEEDED(CoInitialize(NULL))); ATL::CComPtr exe; hr = exe.CoCreateInstance(CLSID_Something,NULL,CLSCTX_LOCAL_SERVER); // call out for .exe component ATLASSERT(SUCCEEDED(hr) && exe != NULL); ATLVERIFY(SUCCEEDED(exe->Dummy())); // access violation here exe.Release(); // doesn't make it to here anywayMy .exe component is non-attributed just like the .dll (not sure if it makes any difference), i have built and registered the proxy-stub class fine, and also my .exe file is registered with "exe /RegServer". i think there is one more thing to be done but just couldn't find out what. if it were the registry script or something, i shouldn't be getting an instance of the .exe component. any ideas ? please have some !! -- modified at 14:18 Thursday 22nd March, 2007 edit: i converted the .exe interface to be non-dual (it was a dual interface before) and this time exe->Dummy() returns "A null reference pointer was passed to the stub."CComPtris a template and its argument is the interface it should contain, e.g.CComPtr<IDispatch>. It looks like you have omitted the interface UUID. It could be a posting error and that "<" and ">" were interpreted as HTML tags. Have you tried using the DLL version as an inproc server? If you haven't, please do so and tell us what happens.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
CComPtris a template and its argument is the interface it should contain, e.g.CComPtr<IDispatch>. It looks like you have omitted the interface UUID. It could be a posting error and that "<" and ">" were interpreted as HTML tags. Have you tried using the DLL version as an inproc server? If you haven't, please do so and tell us what happens.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknowni created another project whose proxy-stub is merged and now the problem is resolved into another one: i use HKEY in some of the functions as in and out parameters (they use registry keys), and my IDL file thinks HKEY is void *, contrary to the caller class, which sees HKEY as struct HKEY__* (as it should). i think this causing inconsistency between the client and the server, since i get "bad variable type" (or something similar) from CoCreateInstance only when there is a method with a parameter typed HKEY in the server. i tried redeclaring HKEY in IDL file,including winnt.h but no luck. any hope here?
-
i created another project whose proxy-stub is merged and now the problem is resolved into another one: i use HKEY in some of the functions as in and out parameters (they use registry keys), and my IDL file thinks HKEY is void *, contrary to the caller class, which sees HKEY as struct HKEY__* (as it should). i think this causing inconsistency between the client and the server, since i get "bad variable type" (or something similar) from CoCreateInstance only when there is a method with a parameter typed HKEY in the server. i tried redeclaring HKEY in IDL file,including winnt.h but no luck. any hope here?
I'm confused about what you're doing. If you're doing what I think you are, in my opinion you've complicated things more than necessary. In your first post you said that the interface was originally a dual interface. This means that it inherits from IDispatch, but a client would have the ability to call the interface methods through vtable calls. There are two major benefits from using an interface that inherits from IDispatch: (a) a wide variaty of clients can use it such as IE and (b) you can rely on typelib marshalling so you don't have to distribute your own proxy-stub DLL. Both (a) and (b) requires that your interface is automation compatible, i.e. the
oleautomationattribute is added to the interface declaration in the IDL file. This also implies that you can only use data type that conforms to automation, i.e. data types that can be represented by aVARIANT. A HKEY cannot be represented in aVARIANT, thus you cannot use it; it won't even make it through the MIDL compiler. Another thing that bothers me is more a design issue. Originally you're creating a out-of-process server. Why would you open a registry key in one process and simply hand it over to another process? I have no idea what the server should do with the registry key, but I suggest that whatever it is it should be given a path where the modifications should be done and open the registry solely. Suppose that the exe-server is distributed to another machine, then it wouldn't even be the same registry. So I guess it's about two questions: 1. What is the server supposed to do with the registry? 2. What are the limitations of the server in the aspect of automation and distribution?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I'm confused about what you're doing. If you're doing what I think you are, in my opinion you've complicated things more than necessary. In your first post you said that the interface was originally a dual interface. This means that it inherits from IDispatch, but a client would have the ability to call the interface methods through vtable calls. There are two major benefits from using an interface that inherits from IDispatch: (a) a wide variaty of clients can use it such as IE and (b) you can rely on typelib marshalling so you don't have to distribute your own proxy-stub DLL. Both (a) and (b) requires that your interface is automation compatible, i.e. the
oleautomationattribute is added to the interface declaration in the IDL file. This also implies that you can only use data type that conforms to automation, i.e. data types that can be represented by aVARIANT. A HKEY cannot be represented in aVARIANT, thus you cannot use it; it won't even make it through the MIDL compiler. Another thing that bothers me is more a design issue. Originally you're creating a out-of-process server. Why would you open a registry key in one process and simply hand it over to another process? I have no idea what the server should do with the registry key, but I suggest that whatever it is it should be given a path where the modifications should be done and open the registry solely. Suppose that the exe-server is distributed to another machine, then it wouldn't even be the same registry. So I guess it's about two questions: 1. What is the server supposed to do with the registry? 2. What are the limitations of the server in the aspect of automation and distribution?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknowni'm trying to create a broker process for an internet explorer toolbar to work on windows vista. internet explorer (only in vista) puts the toolbar on low registry profile on most of the web pages (all except those in trusted zone), which gets things complicated. you open a trusted site and toolbar tries to read from HKCU, you open another site and it tries to read from HKLM\Software\Microsoft\InternetExplorer\LowRegistry... something. so what i'm doing is to use an executable file (which will always work on low profile) to do the trick. toolbar just says "save the setting", and turn away. executable will always save these settings to the LowRegistry key. this is what i understood on msdn articles, did i simply misunderstood them?
-
i'm trying to create a broker process for an internet explorer toolbar to work on windows vista. internet explorer (only in vista) puts the toolbar on low registry profile on most of the web pages (all except those in trusted zone), which gets things complicated. you open a trusted site and toolbar tries to read from HKCU, you open another site and it tries to read from HKLM\Software\Microsoft\InternetExplorer\LowRegistry... something. so what i'm doing is to use an executable file (which will always work on low profile) to do the trick. toolbar just says "save the setting", and turn away. executable will always save these settings to the LowRegistry key. this is what i understood on msdn articles, did i simply misunderstood them?
I don't get why the server has to be an out-of-process server. Do you have any links to the articles that describe this?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I don't get why the server has to be an out-of-process server. Do you have any links to the articles that describe this?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
i'm trying to create a broker process for an internet explorer toolbar to work on windows vista. internet explorer (only in vista) puts the toolbar on low registry profile on most of the web pages (all except those in trusted zone), which gets things complicated. you open a trusted site and toolbar tries to read from HKCU, you open another site and it tries to read from HKLM\Software\Microsoft\InternetExplorer\LowRegistry... something. so what i'm doing is to use an executable file (which will always work on low profile) to do the trick. toolbar just says "save the setting", and turn away. executable will always save these settings to the LowRegistry key. this is what i understood on msdn articles, did i simply misunderstood them?
ajitatif angajetor wrote:
did i simply misunderstood them?
Maybe. The article seems to say that depending on the IL the process "write" operations are restricted. However the lowest IL level has write access to
HKEY_CURRENT_USER\Software\LowRegistry keyso I would believe all higher IL's would as well. It seems that is what you need write access for (based on your post) and therefore you do NOT need a broker process with elevated IL access... if I understand your posts correctly.led mike
-
ajitatif angajetor wrote:
did i simply misunderstood them?
Maybe. The article seems to say that depending on the IL the process "write" operations are restricted. However the lowest IL level has write access to
HKEY_CURRENT_USER\Software\LowRegistry keyso I would believe all higher IL's would as well. It seems that is what you need write access for (based on your post) and therefore you do NOT need a broker process with elevated IL access... if I understand your posts correctly.led mike
nice touch, but the moment you ask for
HKEY_CURRENT_USERin a low integrity process, windows vista will give you theHKEY_CURRENT_USER\Software\LowRegistrykey. so the low integrity process will read/write to a position likeHKEY_CURRENT_USER\Software\LowRegistry\<user_id>\Software\LowRegistry -
nice touch, but the moment you ask for
HKEY_CURRENT_USERin a low integrity process, windows vista will give you theHKEY_CURRENT_USER\Software\LowRegistrykey. so the low integrity process will read/write to a position likeHKEY_CURRENT_USER\Software\LowRegistry\<user_id>\Software\LowRegistry