This is a pretty nasty bug: The installed MitkWorkbench does not start. Several debugging sessions in different configurations revealed, that there is a null pointer access to an ctkPluginContext. However, during debugging, this context seemed to be NOT null.

I think I just solved the mystery: It is a mismatch between the link dependency to BlueBerry stuff and the location where the provisioning mechanism expects the BlueBerry DLLs. I.e., The Wokbench didn't start at all because of missing BlueBerry DLLs despite the fact that they were present in the plugins folder. So we copied these DLLs directly to the same folder as the executable.

Now they were found be the executable but the provisioning mechanism still loads the copies in the plugin folder. This lead to the strange effect that those DLLs are loaded twice (in one version the plugin context is present end this is the version the debugger steps into, in the other version it is null). So there's the mismatch between what we saw in the debugger and the ghosty null pointer access.

I managed to workaround this bug by creating a batch file for starting the Workbench which adds the plugin folder to the path first, so that the link dependencies can be resolved by the executable. Make sure that you delete the BlueBerry DLLS from the bin directory if you copied them here before.

@Sascha, do we really need the hard linker dependencies to the BlueBerry plugins? I guess this is not intended?