locked
WinZip 14 file association message RRS feed

  • Question

  • I'm fairly new to App-V, so apologies if the solution is obvious. I'm sequencing WinZip 14.0 on a Windows 7 sequencer for use in Server 2008 Terminal Services (also tested on a Windows 7 client, same problem). The sequencing works fine, there are no problems launching the application during sequencing. I am using App-V 4.6, entirely 32-bit for now.

    When the package is run on the client I receive a file association message (presumably because .zip/.zipx are associated with sfttray.exe). The message can be cleared by each user, but I'd prefer it to not appear at all.

    With WinZip installed locally the problem can be replicated by deleting the .zip/.zipx associations, and the message can be cleared by creating the string value HKCU\Software\Nico Mak Computing\WinZip\WinZip\AssocMsgZipZipx and setting it to 0 (zero). I have tried creating this value on the sequencer in the Virtual Registry (also AssocMsgZip as suggested here , and both in the same location under HKLM) but it has no effect. I have launched RegEdit under the "bubble" and can see all the values correctly in place, but they seem to be ignored by the sequenced WinZip.

    Thanks.

    Monday, October 4, 2010 11:15 AM

Answers

  • Local Interaction and scripts had no effect.

    I think I've got this resolved however. I finally worked out that a copy of RegEdit run in the virtualised environment shows the "live" registry, so I exported the relevant branch, cleared the message with "Never show again" ticked and compared the registry before and after. It turns out there is an additional registry value created in this situation, also a string, with the name "AssocMsgExe" and set to "0". Creating this value as well in a newly sequenced WinZip package finally got rid of the message.

    I'm not sure what exactly triggers this message. I've tried recreating it on a locally installed copy of WinZip by removing all assocations one by one but haven't managed to find it. Neither Google nor Bing have heard of AssocMsgExe or AssocMsgZipZipx other than this thread, so they're obviously not very common.

    Thanks all for your suggestions - if nothing else I've managed to pick up some decent experience debugging sequenced apps :)

    • Marked as answer by zcaps53 Wednesday, October 6, 2010 12:54 PM
    Wednesday, October 6, 2010 12:53 PM

All replies

  • Hello,

    Are you sequencing on a 32-bit or 64-bit machine?

    /Znack
    Monday, October 4, 2010 6:24 PM
  • Everything is 32-bit.
    Tuesday, October 5, 2010 8:29 AM
  • If memory serves me correctly (at least for version several revisions ago), in WinZip that value is supposed to be DWORD, not string, which may explain why it's not "seeing" it correctly?

     

    • Proposed as answer by znack Tuesday, October 5, 2010 12:54 PM
    • Unproposed as answer by zcaps53 Tuesday, October 5, 2010 3:38 PM
    Tuesday, October 5, 2010 10:31 AM
    Moderator
  • I'm pretty sure it's supposed to be a string - that's what a locally installed copy created (found via ProcMon) and creating it as a string works on a local copy. Every other value in that key is a string too, even though most of them are just 0s and 1s.

    I tested it as a DWORD on a newly sequenced WinZip package anyway and it had the same effect (ie none) as with the string.

    Edit : Creating a DWORD with that name on a locally installed copy doesn't clear the message either. Deleting the DWORD and recreating it as a string on the local copy does work.

    • Edited by zcaps53 Tuesday, October 5, 2010 1:32 PM Additional info
    Tuesday, October 5, 2010 1:09 PM
  • May you could try adding the local interaction tag, see this article http://blogs.technet.com/b/appv/archive/2007/09/20/a-look-under-the-covers-the-local-interaction-allowed-tag.aspx. If this doesn't work, you can always use a pre-launch script to create the registry-key locally, see http://blogs.technet.com/b/appv/archive/2007/04/18/using-scripts-with-softgrid.aspx
    Wednesday, October 6, 2010 5:59 AM
  • Local Interaction and scripts had no effect.

    I think I've got this resolved however. I finally worked out that a copy of RegEdit run in the virtualised environment shows the "live" registry, so I exported the relevant branch, cleared the message with "Never show again" ticked and compared the registry before and after. It turns out there is an additional registry value created in this situation, also a string, with the name "AssocMsgExe" and set to "0". Creating this value as well in a newly sequenced WinZip package finally got rid of the message.

    I'm not sure what exactly triggers this message. I've tried recreating it on a locally installed copy of WinZip by removing all assocations one by one but haven't managed to find it. Neither Google nor Bing have heard of AssocMsgExe or AssocMsgZipZipx other than this thread, so they're obviously not very common.

    Thanks all for your suggestions - if nothing else I've managed to pick up some decent experience debugging sequenced apps :)

    • Marked as answer by zcaps53 Wednesday, October 6, 2010 12:54 PM
    Wednesday, October 6, 2010 12:53 PM
  • I'm not sure what exactly triggers this message. I've tried recreating it on a locally installed copy of WinZip by removing all assocations one by one but haven't managed to find it. Neither Google nor Bing have heard of AssocMsgExe or AssocMsgZipZipx other than this thread, so they're obviously not very common.

    Glad you got it resolved, there's usually always some logical explanation to these things but sometimes they require more or less troubleshooting. ;-)

    As to what triggers the message; I'm pretty sure that it's because during sequencing WinZip sees .zip etc. extensions associated to itself (i.e. winzip32.exe or whatever is the executable) which it recognizes as how things should be. However, when App-V package is deployed to the client, App-V Client creates all FTAs on behalf of actual application and so WinZip probably sees .zip associated to executable it does not recognize, which is of course sfttray.exe! And then it wants to re-associate, something you don't bump into while still in sequencing. That's at least my longstanding theory about WinZip.

    /Kalle

    Wednesday, October 6, 2010 3:52 PM
    Moderator
  • There seems to be two issues - one is if the zip or zipx file association is "wrong". This results in a message which can be suppressed by AssocMsgZipZipx. There is also another check which isn't directly linked to filetype associations, but presumably something to do with the "registration" of the WinZip executable - the resulting message is identical but needs AssocMsgExe to be set to suppress it. I look forward to version 15 when I'm sure they'll add another check which requires a third registry value.
    Thursday, October 7, 2010 10:19 AM