Peter Kaufmann cgl logo
index
publications
research
teaching
misc

Peter Kaufmann
     

Coding

Microsoft Office Lockup

This is not really a coding hint, but some remarks on a problem which bothered me for quite some time now: Whenever I try to 'open', 'save as' or import anything in any of the Microsoft Office applications (Word, Excel, PowerPoint, etc...), the application would just lock up and stops responding. It obviously seems to be related to the file open/save dialog, which just doesn't want to show up. So I went ahead and tried finding out what's going on during the lockup using the Visual Studio debugger and all the debug symbols I could get. It turned out that two threads were locked up. Both of them were trying to access some icon-related data: One of the threads made a call to 'SHGetIconFromPIDL', the other was calling 'CFSIconOverlayManager::_LoadIconOverlayIdentifiers()'. I noticed that one of them had a call to 'LoadLibraryExW' on its call stack, passing the 'TortoiseSVN.dll' file as an argument. And sure enough, after uninstalling Tortoise SVN, the file dialog in Office works ok again!
Of course uninstalling Tortoise SVN is usually not a very practical solution, but if you ever run into the Office lockup problem, it's something you may want to try. Perhaps one day in the future Microsoft or the Tortoise people will do something about this...
UPDATE: After re-installing Tortoise SVN everything works ok again. Perhaps this has been fixed in the latest version. It has also been reported that killing the 'TSVNCache.exe' process could fix this, however I'm not able to confirm this as I cannot reproduce the problem anymore.

Visual Studio 2005

When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Bild and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution: Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.

Qt

You have created a .vcproj file using qmake -t vcapp or qmake -t vclib, and after switching between debug and release builds, you get compile errors such as error C2859: xxx\vc80.idb is not the idb file that was used when this precompiled header was created, recreate the precompiled header.
Reason: When creating a project using qmake -t vcapp or qmake -t vclib, the generated .vcproj unfortunately uses '.\' as the program database file name. This means that the two files vc80.pdb and vc80.idb are written to the directory in which the .vcproj was created. This directory is the same for the debug and the release build, so at some point the release build will try using the vc80.idb file generated by the debug build or vice versa, resulting in the above error.
Solution: Fortunately there is a fix for this. Instead of using qmake -t vcapp to create the project file, pass an additional flag using this not-so-obvious command: qmake -t vcapp "QMAKE_CXXFLAGS=/Fd$(IntDir)\", including the quotes (replace vcapp by vclib to create a library project). This command ensures that the vc80.pdb and vc80.idb files are written to the $(IntDir)\ directory, which is usually Debug or Release, depending on the current configuration. Btw, I only found out how to do this by looking at the source of qmake.

==> Back to Misc