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

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
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
Answered 08/31/2009 by: WayneB
Blue Belt

Please log in to comment
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.
Answered 08/31/2009 by: AngelD
Red Belt

Please log in to comment
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
Answered 09/01/2009 by: Inabus
Second Degree Green Belt

Please log in to comment
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
Answered 09/01/2009 by: Fau
Senior Purple Belt

Please log in to comment
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.
Answered 09/01/2009 by: VBScab
Red Belt

Please log in to comment
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.


Answered 09/01/2009 by: Fau
Senior Purple Belt

Please log in to comment
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
Answered 09/01/2009 by: Fau
Senior Purple Belt

Please log in to comment
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
Answered 09/01/2009 by: Inabus
Second Degree Green Belt

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