Why does Windows keep showing the old indirect strings even after I update the binary?

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

Maurits [MSFT] — Fri, 02 Mar 2012 02:14:15 GMT

> which is a problem because different users can be running different languages

Why is that a problem? Because when different users log in you get cache collisions?

Overcomeable; include the language information in the cache key (or equivalently, have a cache for each language.)

[I'm still surprised you haven't freaked out over Windows having to register a change notification on every single DLL that has evern been seen (and then at every boot, reverifying the cache in case the file was modified while offline). It seems that you're over-engineering the problem. -Raymond]

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

640k — Tue, 28 Feb 2012 11:17:51 GMT

.lnk-files are broken by design.

The fix is, as usual, to reinstall windows.

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

Maurits [MSFT] — Mon, 27 Feb 2012 23:32:12 GMT

Hmmm... let's recap.

Definition: a "perfect" caching system is one that creates a performance boost leaving no other evidence that it exists (no possibility of stale data being returned; no cache poisoning; no authorization bypasses, etc.)

This blog post is a special case of the truism "some caching systems are imperfect."

In this case, it looks like rubbing out the "OMG there's a cache here" evidence would either require reaching out to the .dll (to do a timestamp or hash comparison, losing a lot of the performance gain of the existing implementation) or pushing the problem down to the file system level (in which case it would only work on the new file system.)

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

Maurits [MSFT] — Mon, 27 Feb 2012 23:14:02 GMT

> What if the target DLL is written to while you are logged off? And wouldn't this require the shell to monitor all DLLs which appear in the cache?

So make that a requirement of the cache. "The indirect string cache needs to be invalidated when the target .dll is written to, even if no user is logged on." This just implies that the shell is a bad place to keep the cache.

[This means that the cache must be system-wide, which is a problem because different users can be running different languages. (I guess you could monitor all satellite DLLs, but that quickly explodes into thousands of DLLs being monitored by the system.) Also, what if the file is modified while the operating system isn't even running? (E.g., you boot into another partition and then modify the file, or the file is on a removable drive and is modified while inserted into some other machine.) -Raymond]

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

asdbsd — Mon, 27 Feb 2012 12:08:58 GMT

[There are so many things wrong with this I don't know where to begin. At least two security flaws, possibly three depending on how you count. -Raymond]

I'd like to hear the explanation, if possible. The only flaws I can think of can be fixed with some more or less trivial workarounds.

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

ender — Mon, 27 Feb 2012 08:36:37 GMT

[Often enough that people ask this question because they updated the indirect string without also modifying the shortcut. -Raymond]

I really should have known this would be the answer...

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

dirk gently — Mon, 27 Feb 2012 07:43:39 GMT

To be completely fair, Doctor Who *does* rule and Karen Gillan is pretty hot, so I'm with the developer this time.

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

cheong00 — Mon, 27 Feb 2012 03:13:01 GMT

Emmm... I think if there's a setting in the Windows installer service to force cache update, it should be okay.

Something like "if the user's last logon time to this computer is later than (the last update time of software that requires cache refresh), refresh the user's cache after logon".

[And what if the other users' profiles are not accessible because they are on a roaming profile server you don't have access to? (And in a corporate environment "all other users" can run in the tens of thousands.) -Raymond]

Somehow I think if roaming profile users don't get their cache update, their I.T. should understand, and most probably the users as well (known as common glitches... it's quite common for applications that not designed for roaming profile behave in some "funny" way, and the users have grown accustomed to that, AmIRight?). *Put troll cap on*

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

Paul — Sun, 26 Feb 2012 05:34:18 GMT

Are there any benefits to this feature that are worth all these problems? Why was it implemented in the first place when it was obvious it would be broken for so many scenarios?

re: Why does Windows keeps showing the old indirect strings even after I update the binary?

Stefan Kanthak — Sat, 25 Feb 2012 19:13:15 GMT

| This imaginary InvalidateIndirectStringCache wouldn't solve the problem, since it couldn't invalidate the caches of other users.

| And what if the other users' profiles are not accessible because they are on a roaming profile server you don't have access to?

That's the task of the part of the installer that is run from

[HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\...]

"StubPath"=...