To be quite honest, I am unsure of the cause. I did test this out on Windows XP and it worked perfectly well. I compiled on a Windows 8.1 x64 machine, and launched it on a Windows 7 machine. The console window appeared, as normal, but I wondered why it didn't go away. Interested, I launched it with not gdb, as would be recommended, but instead with Visual Studio (as it would have symbols for all of the Windows libraries). The long startup didn't cause any sort of trap, but the preferences.xml I had did. (the trap seems to happen when you launch with default prefs,  iconify the Fill and Stroke dialog, close it normally, and restart it with gdb: https://bugs.launchpad.net/inkscape/+bug/1317700)

After I had stepped through every single one of the several hundred breakpoints, I could not find the issue (although mainly because the Microsoft devs refuse on releasing the details to their PDB format, and do not seem to support DWARF debug symbols in their debuggers).

I am unable to reproduce the exceptionally long startup time issue, as it went away immediately after the first startup. Possibly a registry key was set. However, the traps are a persistent issue and make my loading time about five seconds longer.

What I am envisioning right now is thousands of people downloading the update, launching Inkscape, and not seeing anything at all (compiled with -mwindows), despite the process showing in Task Manager and consuming many resources. We have also had at least one complaint about this before. (If I could put a bounty on this bug, I would!)

What is this madness?