Windows Explorer shows different third-party context menus in 32-bit mode on Vista 64

I have several third-party applications that add their actions to the menu that's enabled by right-clicking on files in a Windows Explorer. These are tools such as TortoiseSVN.

It usually works fine, but some applications open Windows Explorer windows where these menus are absent. For example, launching a windows explorer window from Cygwin using explorer . &, or using "Explore Files" action in Eclipse results in such state.

Is this a bug in Vista? Is there anything I can do to make Windows Explorer behave consistently?

Clarification Edit:

Actually, upon careful examination, it appears that actually different menu icons appear depending on the invocation mode. E.g. "Unlocker" application only shows up in the "spawned" version, whereas Tortoise and DiffMerge icons show up in the directly launched one.

This is what a "normal" Windows Explorer window should look like on my machine. This was opened using WinKey-E shortcut, or invoked from DOS command shell:

This is what it looks like (examining the same file in the same directory) when launched from Cygwin:

Clarification Edit 2:

I am observing the following differences when launching from Eclipse and Cygwin:

• TortoiseSVN and TortoiseGIT icon overlays don't show up


• Edit with Notepad++ doesn't show up


• TortoiseSVN and TortoiseGIT menus don't show up


• DiffMerge menus don't show up


• Eraser menus don't show up


• 7Zip menus don't show up


• Unlocker menus do show up

To my recollection, of these applications, only Notepad++ and TortoiseSVN were installed when I observed this issue, as well as KDiff3 (I later uninstalled KDiff3 context menus to try to troubleshoot it).

Also, it might be relevant that I'm on the 64-bit Vista.

Update 3:

Thanks to Greech's suggestion, I installed and ran ShellExView, both 32-bit and 64-bit versions. As I was guessing, the two saw different sets items available.

Here are the screen captures for ShellExView 32-bit and ShellExView 64-bit. They are limited to all non-Microsoft entries.

(Open images in new tabs/windows to see full size)

32-bit:

64-bit:

So, the problem reduces to this: when Windows Explorer is spawned from a 32-bit application it gets a different set of menus than when launched from a 64-bit one. To confirm this, I started a 32-bit command prompt using %windir%\SysWoW64\cmd.exe, and launched explorer . inside there. As expected, the 32-bit application menus were visible.

Conclusion

Yes, the problem is that I was running 32-bit Eclipse on 64-bit OS, and it would spawn the 32-bit version of Windows Explorer that didn't have my 64-bit TortoiseSVN/TortoiseGIT menus hooked in. The solution is to install the 32-bit Tortoise versions side by side, as mentioned on the TortoiseSVN downloads page:

Note for x64 users: you can install

both the 32 and 64-bit version side by
side. This will enable the TortoiseSVN
features also for 32-bit applications.

Many thanks to Arjan for asking the right questions, and to Greech for suggesting the key tool to diagnose the underlying issue. I'm going to accept harrymc's answer as it actually comes the closest to the underlying answer, and I don't think there's a way to share the bounty, but I want you guys to know that your help was crucial.

Answer

A similar problem was treated in the following thread : HgTortoise in Vista 64-bit not showing the context menu.

There, the accepted answer was a way to run 32-bit windows explorer on Vista 64-bit using the command:

%Systemroot%\SysWOW64\explorer.exe
/separate

A later update to the thread said:

Update: TortoiseHg 0.8 (released

2009-07-01) now includes both 32 and
64 bit shell extensions in the
installer, and also works with Windows
7. The workaround described below is no longer necessary.

So it seems that your problem is that some products simply install only one version of the extension, either 32 and 64 bits. This is normal, since 32-bit shell extensions cannot be loaded into a 64-bit Windows Explorer, and vice-versa.

A solution would then be, for each such product, to find the missing shell extension 32/64-bits version and to install it in its proper environment.