/build/static/layout/Breadcrumb_cap_w.png

Classes Root Mysterious Key

Hello AppDeploy Community!

Another week, another nice problem to talk about.

So here we go, I packaged WinRAR 3.90 this morning via Setup Capture. I have a key that is created under:

HKCR\WinRAR\shell\open\command
<default>="[ProgramFilesFolder]\WinRAR\WinRAR.exe" "%1"

However, when I install the said MSI, I don't run WinRAR yet, I have another entry which pops in this key which reads the following:

"Command" which is a type "REG_MULTI_SZ", with data "yDMSRHrr?=}r6d]'}}'>Vb_j_Mc_F9Esdk5v_v(s"

This key causes a problem, since my RAR files won't open when I double click the file. If I delete this, my problem is solved.

I searched thru and thru in the Registry view, Registry table and WHOLE MSI tables, and I can't find anything on such a key.

Which makes me wonder where this key comes from? Do you guys have any clues for me as to what I could do?

Thanks all!

Stephane

0 Comments   [ + ] Show comments

Answers (8)

Posted by: WayneB 14 years ago
Blue Belt
0
Hi Stephane,

You could imbed a script to set ASSOC and FTYPE file association properties. A way to investigate what to set is to run something like InstallWatch after you have deleted the problem registry entries and then taking a snap after WinRAR is launched for the first time. This should give you the required information. A verbose log will tell you where the key came from.

And our good friend VBScab will entertain you with ProcMon familiarisation; won't you Ian? :)

Your mysterious key looks like some sort of legacy build command from something else you have installed on the OS.

Enjoy the Investigative process, I look forward to hearing your resolution Stephane.

Regards
Wayne
Posted by: AngelD 14 years ago
Red Belt
0
Looks just like a classic Darwin Descriptor (entry point).
It's normal when installing shortcuts, file associations as advertised instead of a "normal" resource.

If you're having problem with advertised file associations then change it as non-advertised instead.
Posted by: Inabus 14 years ago
Second Degree Green Belt
0
Check the Verb table!

My betting is you have an entry there, plus the entry in the Registry table.

Thus remove one of them, I recommend the Registry table entry, if you dont have a verb entry then remove the Registry entry and add it, in the correct format, into the Verb table.

Also if your winrar package takes over the .zip extension make sure you put .zip back to windows builtin .zip functionality on uninstall.

P
Posted by: Fau 14 years ago
Senior Purple Belt
0
Hello again guys,

Ok, I may be misunderstanding your different troubleshooting paths... You all seem to be pointing me in the File Associations way... I'm not sure why?

Like I said, my problem lies in the HKEY_CLASSES_ROOT\Winrar\shell\open\command key.

I do indeed have a ton of File Associations for each of the associations that WinRar covers. I also have entries in both Verb and Registry tables for each file association which reads for example, in Verb:

.rar open
.zip open
etc etc

Anyway, perhaps helping me understand the link between file associations and my mentionned key above will help me understand?

Thanks!

I'll try and look at your suggested troubleshooting in the meantime!

Stephane
Posted by: anonymous_9363 14 years ago
Red Belt
0
I'm not sure why? Check out the entry HKCR\.rar. You should see that the '(Default)' is set to 'WinRAR'. That's registry shorthand for 'HKCR\WinRAR'.

All file extensions are handled this way.

Aside:
Quite why MS chose this tortuous route when it seems to me that the entire tree could live with the extension definiton is anyone's guess, but we're stuck with it, the same as we're stuck with the brain-dead two-branch tree (and circular references) for class IDs, TypeLibs etc.
Posted by: Fau 14 years ago
Senior Purple Belt
0
As usual, you are quite right on that one!

But, on a side note, am I handling File Associations the recommended way? Or is there some other way I should go about, perhaps even avoiding the hassle I'm having at the same time?

Thanks!

Stephane

should ORIGINAL: VBScab

I'm not sure why? Check out the entry HKCR\.rar. You should see that the '(Default)' is set to 'WinRAR'. That's registry shorthand for 'HKCR\WinRAR'.

All file extensions are handled this way.

Aside:
Quite why MS chose this tortuous route when it seems to me that the entire tree could live with the extension definiton is anyone's guess, but we're stuck with it, the same as we're stuck with the brain-dead two-branch tree (and circular references) for class IDs, TypeLibs etc.


Posted by: Fau 14 years ago
Senior Purple Belt
0
Problem solved!

I deleted ALL File Associations from Wise Package Studio's "File Association" section under the Installation Expert tab. And I'm now problem free.

Which means that probably my File Associations where there in double. Why? I have absolutely no clue!

Stephane
Posted by: Inabus 14 years ago
Second Degree Green Belt
0
If you want to understand why tools like Installshield and Wise leave stuff in the registry when its also in the relevant tables, i.e. Class, ProgId then I would recommend starting to write a vbscript to resolve ICE33's :)

As for your fix, you have removed the ability to do proper self repair of your application now through the deletion of the relevant registry keys. As an example delete one of the keys assosicated with winrar, i.e. HKCR\.rar and then on launching your app, it wont self repair, assuming the key isnt set as the keypath of its component. This would self repair if the entries where in the relevant Verb / Extension table.

P
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