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

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

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.
Answered 10/30/2008 by: AngelD
Red Belt

Please log in to comment
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)?
Answered 10/30/2008 by: captain_planet
Second Degree Brown Belt

Please log in to comment
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.
Answered 10/30/2008 by: pgiesbergen
Orange Belt

Please log in to comment
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
Answered 10/30/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
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
Answered 10/30/2008 by: captain_planet
Second Degree Brown Belt

Please log in to comment
0
Just read your response, Inabus, and I'm going to try it first thing in the morning. Thanks....
Answered 10/30/2008 by: captain_planet
Second Degree Brown Belt

Please log in to comment
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
Answered 10/30/2008 by: AngelD
Red Belt

Please log in to comment
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.
Answered 10/31/2008 by: captain_planet
Second Degree Brown Belt

Please log in to comment
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
Answered 11/04/2008 by: DLL_HELL
Senior Yellow Belt

Please log in to comment
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.
Answered 11/04/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity