System.AccessViolationException on AnkhSVN with Visual Studio

As quite a few other developers, I use Subversion as my Source Code Control. Being mainly a .net Developer, I am using Visual Studio to do my work, and that means I needed a Subversion-integration for Visual Studio. My choice is AnkhSVN, specifically Version 1.0.3. Yes, it's pre-release, but it works a lot better than 1.0.2 which loved to put my repository in a state where I had to run the cleanup command first before I could commit. (Renaming, Deleting and moving files within the solution is somethink that could reliably mess up AnkhSVN, and 1.0.3 is a big improvement).

Since I have recently upgraded my PC (From an Athlon 64 X2 4200+ to an Intel Core 2 Quad Q6600), I also reinstalled Windows XP and the applications that I need, including Visual Studio and AnkhSVN. But to my surprise, I started getting Access Violations when starting or using any AnkhSVN Feature:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at svn_config_get_config(apr_hash_t** , SByte* , apr_pool_t* )
at NSvn.Core.ClientConfig.Init(String dir) in e:\projects\2003\ankh\build-3\src\nsvn.core\clientconfig.h:line 73
at NSvn.Core.ClientConfig..ctor() in e:\projects\2003\ankh\build-3\src\nsvn.core\clientconfig.h:line 21
at NSvn.Core.Client..ctor() in e:\projects\2003\ankh\build-3\src\nsvn.core\client.cpp:line 95
at Ankh.AnkhContext.SetupFromConfig() in E:\projects\2003\Ankh\build-3\src\Ankh\AnkhContext.cs:line 552
at Ankh.AnkhContext.LoadConfig() in E:\projects\2003\Ankh\build-3\src\Ankh\AnkhContext.cs:line 516
at Ankh.AnkhContext..ctor(_DTE dte, AddIn addin, IUIShell uiShell) in E:\projects\2003\Ankh\build-3\src\Ankh\AnkhContext.cs:line 49
at Ankh.Connect.OnConnection(Object application, ext_ConnectMode connectMode, Object addInInst, Array& custom) in E:\projects\2003\Ankh\build-3\src\Ankh\Connect.cs:line 89

Hmmm... That looks bad. After some searching and even a memory test (Access Violation is often also a sign of faulty memory, especially if they suddenly start appearing), I found that it was caused by an installed Subversion (if you look into the stacktrace, AnkhSVN eventually goes into Subversion, which then throws the somewhat misleading exception). I do always have the Command Line Version of Subversion installed, in case I want to check out some repository outside of Visual Studio. After renaming the C:\Program Files\Subversion Folder, AnkhSVN works perfectly fine.

It looks as if AnkhSVN was linked against a different Version of Subversion, or in some other way is incompatible with the stuff it finds in my standalone installation. Specifically, it is libapr-1.dll that is causing that issue. If I remove it from my %PROGRAMFILES%\Subversion\bin Directory, Ankh works fine, but obviously the standaone Subversion does not. Armed with that clue, I was able to find the reason:

Subversion-1.4.6 for Apache-2.0 uses APR-0.9(libapr.dll). But Subversion-1.4.6 for Apache-2.2 uses APR-1.2(libapr-1.dll).

Yep, I am indeed using Subversion for Apache 2.2 which uses APR-1.2 (APR stands for Apache Portable Runtime Library), but AnkhSVN uses APR-0.9 and despite them having different filenames, they are referencing each other somehow and as a result, it crashes.

The solution? Since I do not run Apache Web Server on that machine, I just uninstalled Subversion and reinstalled the version built against Apache 2.0 instead - works perfectly! (For normal Desktop use, there is no advantage or disadvantage of using a specific version, it is really only if you want to use Subversion with Apache, as outlined in an older article by me). If you ARE using Apache, I don't really know how you could resolve it. One guess is to install the Apache 2.2 package, grab the required .so files, uninstall it and install the 2.0 package while placing the 2.2 packages into the Apache extensions. But I have no idea if that works. If not, it looks like you're in for some recompiling to compile your own compatible versions of your tools.

Anyway, I'm back to having a working Development Environment and I'm working on the next version of my CommandLine Tools.