/build/static/layout/Breadcrumb_cap_w.png

InprocServer repair issues?

Hi folks.

I'm a bit confused. I'm drafting up an example to try and illustrate the repair of registry entries which are written using the Class table.
I always understood that every single entry in this table would act as repair entry points. However, it doesn't seem to be working. Here's what I'm doing (all on a virtual machine):

Created a simple VBScript (test.vbs):
set fso = CreateObject("Scripting.FileSystemObject")
fso.CreateTextFile("c:\test.txt",true)

Then, I installed my sample MSI which registers scrrun.dll (which contains COM class for the filesystem object) via the class table. It populates the registry fine when it is installed. When I run the script, it works fine too.

However, I then manually delete the inprocServer32 entry which points to scrrun.dll. When I instantiate the 'Scripting.FileSystemObject' via running the script, I would expect it not to find the scrrun.dll (because I've removed the inprocServer32 entry) and then repair this registry entry. However, it does not find the dll and most importantly does not repair??

So then I set the feature to favour advertising. When the InprocServer32 KEY (not value) was created, an InprocServer32 reg_multi_sz value was created which contained what appeared to be a Darwin descriptor (and not the path to the dll). Great - it knows where to repair the registry key from. I run the script first time and the inprocServer32 value is repaired, and now contains the path to the dll. We have now lost the darwin descriptor and the script runs fine. I then delete the inprocServer32 value, run the script, and again it doesn't repair?

I thought instantiating a COM class from a progId would trigger a repair? But it doesnt? Can anybody shed light on this subject?

0 Comments   [ + ] Show comments

Answers (10)

Posted by: AngelD 15 years ago
Red Belt
0
I think you're mixing it up.
The Darwin Descriptor is an entrypoint and when a entrypoint is invoced self-healing comes in place to check for any broken components.
If you remove the entrypoint (Darwin Descriptor registry entry) then another entrypoint would have to be triggered for the Windows Installer resiliency function. You need to remove the keypath for the component rather then the actual entrypoint, my guessing it would be the scrrun.dll file.
Posted by: captain_planet 15 years ago
Black Belt
0
Thanks for your reply, AngelD. It still doesn't clarify my problem though. I thought that one of the major advantages of using the advertising tables (Eg Class table) as opposed to the Registry table was due to the resiliency side of it - the ability to repair when a registered class is instantiated? I thought that every row in the Class table effectively acts as a keypath/an entry point? In which case it should be repaired if I call an instance of it via a script (assuming it's been removed)?
Posted by: pgiesbergen 15 years ago
Orange Belt
0
A Class does not act as a keypath, therefore deleting the inprocserver32 (default) key does not have any effect, but if you delete a file or registry key that is a keypath for another component, and call the class someway then selfhealing will kick in. It is similar to an avertised shortcut. Removing an advertised shortcut does not trigger self healing also if you start another advertised shortcut of the same package.
Posted by: Inabus 15 years ago
Second Degree Green Belt
0
Yes, classes, progid's, typelibs and odbc entries CAN be entry points. I suspect that your not actually calling the entry point in the inproc key correctly.

I am under the impression that I can create folders, using vbscript on a core xp machine without anything installed, and therefore this means your calling a core bit of vbscript functionality inside the O/S.

I would find a file, like SYSINFO.OCX, register it and call its functions via VBSCript and then delete com information, this will then work as this file isnt part of the O/S.

P
Posted by: captain_planet 15 years ago
Black Belt
0
Thanks pgiesbergen. I agree with your response, and have simulated the behaviour described and it worked as expected. However, in relation to 'repair' there doesn't seem to be an advantage with registering a CLSID using the Class table, or registering a CLSID using the registry table? Because as you say, it seems to depend on the file keypath being present in any case?

Excuse me if I'm being thick, but in the following article it says "....are considered as special keys because they can be used as advertised entry points to the application...". When it says they can be used as advertised entry points, can anybody give me a clear example of what this is referring to? Hmmmmm. I'm confused.

http://www.installworld.com/index.php?view=article&catid=42%3Aice&id=203%3Aice33&option=com_content&Itemid=138&3b02ec39bd9b1d3605765db12a22b05b=8c7211da3f14442c7ffea962d48a73fc
Posted by: captain_planet 15 years ago
Black Belt
0
Just read your response, Inabus, and I'm going to try it first thing in the morning. Thanks....
Posted by: AngelD 15 years ago
Red Belt
0
"they can be used as advertised entry points to the application"
What it means is that if the application calls any entrypoint then it can trigger a repair if any broken component is found ex. missing keypath.
Calling an entrypoint makes the Windows Installer resiliency function check every component in the feature the entrypoint is located in an every component in every parent feature of that feature. If one component is found broken either a Component or Feature level repair will occur.

A broken component must have been found for the repair to occur, so if the registry you removed (InprocServer registry entry also a entrypoint in this case) was a keypath of a component then a repair would happen but as this isn't the case the repair does not happen.

Hope that helps
Posted by: captain_planet 15 years ago
Black Belt
0
I would find a file, like SYSINFO.OCX, register it and call its functions via VBSCript
Yep it worked with that DLL, thanks.....

What it means is that if the application calls any entrypoint then it can trigger a repair if any broken component is found
AngelD - that clarifies my thinking. Great. Thanks.
Posted by: DLL_HELL 15 years ago
Senior Yellow Belt
0
Captain_Planet

Please chack out this link for information on self-healing and darwin descriptors etc

http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=amonth%3d3%26ayear%3d2008

It is very helpful
Posted by: jmcfadyen 15 years ago
5th Degree Black Belt
0
the benefits gained from this method is that you no longer rely on the use to run a shortcut to trigger self repair checking functions.

this is beneficial mainly when applications do not get started from shortcuts etc.

for example your application could simply be just a bunch of com dll's.

as running code that access the com would be enough to trigger self repair.

based on those assumptions it is a good idea to have both the com registry and the com assembly in the same component. usually marking the assembly as the keypath is the way forward.

if you saw some crazy stuff in your inproc registry keys such as #$^$%&#%^*@$*^#%*@#^#%( it is likely to be your entry point.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ