Debug DLL and Visual Studio Debugger

Combat Wombat said:

So in conclusion Afforess is quite right this is only explainable by laziness on the part of Fraxis.

Click to expand...

In that case can you explain why the disc version works and the steam version doesn't? Early disc versions had copy protection and needed the disc while playing. However more recent versions have skipped this, which mean when they made the steam version, why didn't they simply use the disc exe? Obviously if the disc exe works just fine from anywhere on the HD, then the lazy solution would be to zip the disc installed version and distribute that one.

I'm not convinced by the laziness at all. Crashing only when a debugger is used is actively added. I can't think of a single scenario where Firaxis could have added it by mistake. I could however imagine some interconnection with steam and then Firaxis didn't realize the issue they would give modders. Either that or they didn't care.

Nightinggale said:

In that case can you explain why the disc version works and the steam version doesn't? Early disc versions had copy protection and needed the disc while playing. However more recent versions have skipped this, which mean when they made the steam version, why didn't they simply use the disc exe? Obviously if the disc exe works just fine from anywhere on the HD, then the lazy solution would be to zip the disc installed version and distribute that one.

I'm not convinced by the laziness at all. Crashing only when a debugger is used is actively added. I can't think of a single scenario where Firaxis could have added it by mistake. I could however imagine some interconnection with steam and then Firaxis didn't realize the issue they would give modders. Either that or they didn't care.

Click to expand...

The Securom DRM on the discs was part of the EXE made by Firaxis while they still supported the game actively. The debugger worked because the DLL's were made to match these EXE files produced by Firaxis.

I suspect to fix the GameSpy mess, some poor intern at Firaxis got pointed to some ancient archive with the source code for Civilization 4 and was told to "make it work". After a week of hacking, an EXE that didn't crash was produced, was shipped out, with nary a thought about modders, affects on the DLL, etc.

On the other hand, if the theory about the VAC/Steam injection is true (which it might, the EXE might be modified to include the Steam overlay, for example), then I still blame Firaxis. The EXE is signed by Firaxis, so if Steam is modifying it, then Firaxis gave Valve their signing key, and so Firaxis is still to blame.

Afforess said:

I suspect to fix the GameSpy mess

Click to expand...

The problem appeared before the GameSpy issue, at least for Colonization.

Afforess said:

Firaxis is still to blame.

Click to expand...

Sure they are. They are just as responsible as if they made a broken disc version. They might not have discovered it prior to release, but it's not like it's hard to add a bugfix release to a game on steam. They had no problem fixing GameSpy and send out an update for that, though that broke directIP connection and the ability to use mods in multiplayer, which in my eyes is far worse than no GameSpy. They did add the ability to downgrade to regain those features though.

Whatever the reason, do use the disc version. The rest is pure speculation and the reason will not change the conclusion.

Nightinggale said:

If you can get hold of a pdb file for the exe, then I would be overjoyed. However odds are that it is a well kept secret

Click to expand...

Yeah, I was afraid this is the case
I just didn't really want to believe, that all those supposedly very useful .dmp files are totally worthless to the modders
Especially since there is the built-in function which generates dump files on crash (both normal (mini)dump files, and full dump files). It's a shame the whole thing is there only for their own benefit.

I think there is a major issue regarding not knowing the exe as the dmp file has memory addresses (I think) and the exe pdb sets an offset for memory for the DLL. However lets assume this isn't the issue and instead brainstorm for what we can do something about.

The makefile will not generate a pdb file when compiling a release file, only a debug file. Since those two files are different, you can't take the pdb file from one and use on the other. The dmp file has addresses for a release DLL meaning you can't use a debug DLL to see what goes on. The only thing I can think of, which might work is get the newest Makefile and compile a profile DLL. It has the release optimization, but at the same time it generates a pdb file. It is actually intended for profiling (figuring out how much time each line of code uses), but maybe it can be used for this.

Click to expand...

Actually I can generate .pdb files for a release dll too
But it's kinda pointless. as I said, even when I attach the source code and the symbols with the .dll to the dump file, it still asks for the .pdb for the exe too.
And otherwise there is no real use for pdb files for the release dll, at least I never needed them before

Having said this, using the debugger at runtime is likely way more efficient, but sure enough it mean you have to repeat the bug. In fact I think the only time where dump files could be interesting is with random crashes.

Click to expand...

Yeah, that's probably true
My main goal was to avoid the bug repeating process, but it seems Firaxis kept this privilige to themselves

Debugger setup
While on the topic, I figured out a way to start the game from Visual Studio and attach the debugger. I haven't written a guide to do it manually yet (I plan to write one with screenshots and stuff), but in the meantime there is a perl script, which will set up the project files automatically here:
http://forums.civfanatics.com/showthread.php?p=13825363#post13825363

Click to expand...

Should be useful
Looking forward to the guide!