Sharing violation with MsiShortcutProperty table

[Adrian Accinelli]

With Windows 7 and the introduction of new Taskbar with jumplist etc it is a
good bet that many applications installing using MSI packages will make use
of the MsiShortcutProperty table. Makes your application shine and all
that...

In some rare circumstances (less than 5% of installs) when using this table
in an MSI I have seen error 1946 come up. This is a warning really but
typically will stop the install until the user acknowledges it so is an
annoyance. In each case the associated system error code is 32 which is
ERROR_SHARING_VIOLATION.

It's important to note that this particular problem has nothing to do with
incorrect or badly formatted PropertyKey/PropVariantValue field contents.
The exact same MSI can be installed fine (with correct property values set
in all the LNK files) and then subsequently removed and installed again only
to receive the warning. Similarly after seeing the warning the same install
can succeed twenty more times in succession.

I am interested to know whether or not others have come across this
behaviour.

Sincerely,
Adrian Accinelli

[dbareis [Windows Installer MVP]]

Hi,

On Oct 15, 3:00 am, "Adrian Accinelli"
<hclnospamali...@newsgroup.nospam> wrote:

> In some rare circumstances (less than 5% of installs) when using this table
> in an MSI I have seen error 1946 come up.  This is a warning really but
> typically will stop the install until the user acknowledges it so is an
> annoyance.  In each case the associated system error code is 32 which is
> ERROR_SHARING_VIOLATION.

My guess is the Windows indexing (or other similar) service and lack
of retries in Windows Installer.

Bye,
Dennis

[Adrian Accinelli]

"dbareis [Windows Installer MVP]" <dba...@gmail.com> wrote in message
news:b6238dbe-2572-4068...@x25g2000prf.googlegroups.com...

You are probably right. I didn't do much investigating to narrow down the
exact cause but it seems like the creating of the shortcuts and setting of
the properties are performed as separate operations which allows for this
locking issue to come up in the first place.

Sincerely,
Adrian Accinelli