§ ¶Odd requirement for the Set Program Associations UI in Windows 8

Okay, this is another one of those frustrating bugs that took me hours to track down and had a cause so unbelievable I had to check it six times: why the Set Program Associations UI dialog refused to come up for a program in Windows 8, but worked fine on Windows 7 x64.

From what I've been able to tell, the LaunchAdvancedAssociationUI() call in the IApplicationAssociationRegistrationUI interface has a new requirement in Windows 8 that is strange and undocumented. Specifically, the shell verb commands in the ProgIDs that are specified in the program's FileAssocations registration key must point to an executable with a valid CompanyName field in its version block in order to be considered valid. If this executable doesn't exist or the CompanyName field is missing, the ProgID is skipped, and if no valid associations are detected, the call will fail with the HRESULT 80070490. Even more confusing, if there was previously an executable at that location which had CompanyName, the call will succeed and show the cached name instead, so to double-check this you need to rename executables to different names. Basically, if you are having trouble bringing up the Set Program Associations UI dialog, throw something into that version field for it to display.

§ ¶File dialogs break in capture mode with UScreenCapture driver

If you are using VirtualDub with the UScreenCapture driver to capture video from the desktop screen, you may run into problems with the Set Capture File option in VirtualDub not bringing up a file dialog, at least on Windows 7. This appears to be due a problem within v2.0.14 of UScreenCapture.ax which also reproduces with Microsoft GraphEdit. I am trying to contact the vendor for a resolution, but have not gotten a reply as of yet.

Technical details:

VirtualDub's file dialogs fail to come up because of an internal error within the Windows common file dialog. The specific failure path is GetSaveFileName() -> DialogBoxIndirectParam() -> CreateWindowEx(ComboBoxEx) -> SetWindowSubclass() -> GlobalAddAtom(). That in turn is caused by UScreenCapture's worker thread calling SetProcessWindowStation() with a handle to WinSta0 that does not have the WINSTA_ACCESSGLOBALATOMS access right. This only happens while the capture driver is running, but as it pretty fundamentally borks UI process state, it's not something I can easily work around safely.