Did you make sure to change the PATH environment variable accordingly, e.g. by starting the solution with the startVS_release.bat batch file?

The PATH is set accordingly and starting the workbench with the batch results in the same error. We checked that already.

With the current master, the application doesn't seem to crash anymore. However, the Application stops after showing the four window view. There are no other GUI items visible (no Datamanager or Menubar). The Application also doesn't response to anything but closing its console view, leading to a proper shut down of MITK.

When running Release in Debug mode, I get this output:

The thread 'Win64 Thread' (0x1180) has exited with code 0 (0x0).
First-chance exception at 0x64c6868f in SandboxApp.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
Unhandled exception at 0x64c6868f in SandboxApp.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Same error is shown when starting MBIApp and the call stack location is somewhere in QtGui4.dll

Since we both use the same Qt4-build (4.8.3. x64 VS2010), we thought about a broken Qt release library. However, everything worked fine for Michael with a 2 month old master.

The application also gives the following warning, which i haven't seen before:

0.32 blueberry.ui.wrkbncPlg: LOG: Warning: Detected recursive attempt by part or
g.mitk.views.datamanager to create itself (this is probably, but not necessarily
, a bug)
0.39 blueberry.ui.wrkbnc: BlueBerry Workbench ready

Seems to be a x64 problem. With my 32-bit laptop (Qt 4.8.3 32bit, VS2010, Windows8, latest master) the workbench starts without problems in release-mode.

Does this crash appear for the MITK Workbench application or only for the "MBIApp"? In the latter case, please change the product to MITK-mbi

The crash occurs with MITK and MITK-mbi.

Is this still happening? I have used a visual studio 2010 build MITK Workbench in the past weeks and did not notice any issue. This includes building installers.

I will try to reproduce this.

Build current master on Windows 7 64 Bit Visual Studio 2010 as 64 Bit application.

MITK Workbench started fine.

Maybe your issue is not due to VS 2010 64 Bit at all but some other reason?

Setting this bug to works for me, you might want to reopen and rename it if the issue persists on your machine.