[gme-users] Compiling issues (pt 2)

Toth, Csaba csaba.toth at Vanderbilt.Edu
Fri Apr 27 21:05:09 CDT 2012

What I'd also be sure is to include the debug symbol files for each dll and exe you compile. This way the crashdump reporter can extract more information at the time of the crash. This is true for both Debug and Release version of the program. If you install Debug version then the crash report much likely to be able to unfold the call stack of the crash (Release often have too much optimization which affects the stack). But for Debug version you need to include several dlls which are not present on a non-developer environment.
Kevin: I cannot remember if there's a registry switch to obtain crash dump or how that goes now.

You can also try remote debugging.

My bet: You probably have some issue with some dlls or COM components, if GME dies so soon.

- former developer.
From: gme-users-bounces at list.isis.vanderbilt.edu [gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Kevin Smyth [ksmyth at isis.vanderbilt.edu]
Sent: Friday, April 27, 2012 1:57 PM
To: gme-users
Subject: Re: [gme-users] Compiling issues (pt 2)

For problems like these, I would use Process Monitor to try to see what is failing.

Here's my guess:
GME depends on quite a few ActiveX dlls, which you wouldn't see in Dependency Walker. GME uses the standard CoCreateInstance method to create these, which depends on HKCR COM registration data. This registration data is created by GME.sln (and MetaGME.sln et al) by running regsvr32 on the various COM dlls. The registration data is created by GME.msi for installed versions. If you didn't install GME.msi on your VM, the VM would not have the registration data.

Instead of zipping up anything, I'd use the Install\Build\build.py build script to build a GME.msi and install that. (You'll need to install Python 2.6 or 2.7 and WiX 3.5.) That will create all the COM registration data you'll need (and also compile other required components, like the MetaInterpreter and MetaDecorator). The msi also provides uninstall.

If using the msi doesn't help, let me know and I can list some debugging breakpoints.

Also note GME will silently exit on Windows Server Core.


From: gme-users-bounces at list.isis.vanderbilt.edu [mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Andrew N
Sent: Thursday, April 26, 2012 7:07 PM
To: gme-users
Subject: [gme-users] Compiling issues (pt 2)

I am running into a bit of a roadblock which I'm having difficulty debugging. Apologies in advance for soliciting help with such a vague description of the problem, but the reason the description of the problem is so vague is the same reason I'm having difficulty finding a solution.

I added a few elements to the IDR_MAINFRAME resource file and compiled successfully, ran the executable on my local machine and zipped it up to send out for QA. I got a message saying that the binary, when double clicked, did nothing. I fired up a brand new VM and saw the same error happen. I double click the exe,see the hour glass for about 1/4th a second,then nothing happens. I don't even know how/where to start debugging it. I threw the bin into IDA to see if it could make heads or tails out of it and it couldn't either. I tried Dependency Walker too to no avail. Out of curiosity, I tried building a GME build fresh out of the source zip file of 12.4.20 -- same problem. This is all being done in elevated mode with the Release configuration.

I'm guessing this is a compiler flag issue or something or perhaps something is not being (statically?) linked properly. But I've no idea as how to debug this issue, and less of an idea as how to fix it.

Any help would be much appreciated.

More information about the gme-users mailing list