Millard12EqWithAff.exe has stopped working
Posted: Fri Dec 30, 2016 8:14 am
Hello,
I'm a student researcher, and have found the article corresponding to this software very useful. I think I'll find the software very useful as well, but I currently seem to be unable to run the generated .exes. I take the typical c++-to-executable steps for successfully running OpenSim exampleMain, etc., as I have before: build with CMake pointed to the source folder (and to a build folder within); open created solution folder in Visual Studio and build in RelWithDebug (the error is reproduced with Release) x64 (I'm using a 64-bit machine and processor, and used CMake's Visual Studio 14 2015 Win64 generator) configuration; and open the resulting .exe. However, if I open Millard12EqWithAff.exe in either the RelWithDebug or Release folders, a console window (like the window of command prompt) appears, as one would in successfully created exampleMain etc. programs, with the words 'MODEL: tugOfWar'. About a second later, a Windows window pops up with the header 'Millard12EqWithAff.exe has stopped working' and the text 'Windows is checking for a solution to the problem...'. After about one more second, the text changes to 'Windows is collecting more information about the problem. This might take several minutes...' and pretty much immediately after that, it becomes 'A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.'. Two buttons are at the bottom of the last screen, one to 'Debug' which opens the .exe in the Visual Studio debugging GUI, and another to 'Close Program'. I've reproduced the same issue on another computer with a 64-bit OS and processor running Windows 10, using OpenSim 3.3, CMake 3.6.3, and Visual Studio Community 2015 as my first computer did. The error also occurs using CMake 3.7.1 on my first computer. Now, if you choose 'Debug' and use the Visual Studio debugging GUI with a 'New instance of Microsoft Visual Studio 2015' as the debugger, you run into breaks very often with the error message:
'Unhandled exception at 0x00007FF95E25B5EB (msvcp120.dll) in Millard12EqWithAff.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
If there is a handler for this exception, the program may be safely continued.'
If you were to press continue after this break and for other breaks, I noticed the message is sometimes just:
'Exception thrown at 0x00007FF95E25B5EB (msvcp120.dll) in Millard12EqWithAff.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
If there is a handler for this exception, the program may be safely continued.'
I've found forums where this error message signifies pointer/null issues such as having null pointers passed to run-time functions or having variables which weren't previously initialized null.
I will continue to work on the problem, but wanted to let you know in case this is a widespread issue, and since you're probably more familiar with the code (and code in general) than me and thus I believe you could find any null pointer issues much faster than me.
Thanks,
I'm a student researcher, and have found the article corresponding to this software very useful. I think I'll find the software very useful as well, but I currently seem to be unable to run the generated .exes. I take the typical c++-to-executable steps for successfully running OpenSim exampleMain, etc., as I have before: build with CMake pointed to the source folder (and to a build folder within); open created solution folder in Visual Studio and build in RelWithDebug (the error is reproduced with Release) x64 (I'm using a 64-bit machine and processor, and used CMake's Visual Studio 14 2015 Win64 generator) configuration; and open the resulting .exe. However, if I open Millard12EqWithAff.exe in either the RelWithDebug or Release folders, a console window (like the window of command prompt) appears, as one would in successfully created exampleMain etc. programs, with the words 'MODEL: tugOfWar'. About a second later, a Windows window pops up with the header 'Millard12EqWithAff.exe has stopped working' and the text 'Windows is checking for a solution to the problem...'. After about one more second, the text changes to 'Windows is collecting more information about the problem. This might take several minutes...' and pretty much immediately after that, it becomes 'A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.'. Two buttons are at the bottom of the last screen, one to 'Debug' which opens the .exe in the Visual Studio debugging GUI, and another to 'Close Program'. I've reproduced the same issue on another computer with a 64-bit OS and processor running Windows 10, using OpenSim 3.3, CMake 3.6.3, and Visual Studio Community 2015 as my first computer did. The error also occurs using CMake 3.7.1 on my first computer. Now, if you choose 'Debug' and use the Visual Studio debugging GUI with a 'New instance of Microsoft Visual Studio 2015' as the debugger, you run into breaks very often with the error message:
'Unhandled exception at 0x00007FF95E25B5EB (msvcp120.dll) in Millard12EqWithAff.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
If there is a handler for this exception, the program may be safely continued.'
If you were to press continue after this break and for other breaks, I noticed the message is sometimes just:
'Exception thrown at 0x00007FF95E25B5EB (msvcp120.dll) in Millard12EqWithAff.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
If there is a handler for this exception, the program may be safely continued.'
I've found forums where this error message signifies pointer/null issues such as having null pointers passed to run-time functions or having variables which weren't previously initialized null.
I will continue to work on the problem, but wanted to let you know in case this is a widespread issue, and since you're probably more familiar with the code (and code in general) than me and thus I believe you could find any null pointer issues much faster than me.
Thanks,