Debug DLL and Visual Studio Debugger

[Afforess]

This thread is meant mainly for 45* and myself, and anyone else familiar with the SDK and Visual Studio.

So what I have discovered coming back to RAND 2 is that I can't do any real time debugging with the Debug DLL. When the debug DLL is built, it doesn't include many optimizations made in the release DLLs and includes debugging symbols, which allow real-time inspection of the code.

Normally, to debug BTS, you build a debug DLL, replace the existing DLL in the mod, and launch the game. Once the game starts loading (either XML or at the main menu, both work) you can use the Visual Studio option to attach a debugger to a process, and select the Civ4BeyondTheSword.exe to debug. While attached, you can set breakpoints, which will pause the game and let you debug, and the game will jump to code if an exception is thrown (normally an exception causes the game to crash). I first thought my setup was to blame. I was using Visual Studio 2008 Express, but I went and installed Visual Studio 2013 Ultimate Edition (I have the license key, yay) and set it up to build civ4 DLL's. It has exactly the same problem.

So right now when I attach Visual Studio to the process, I see the normal debug window console output. But if I attempt to set a breakpoint and debug, or encounter an exception, the game crashes immediately, without jumping to the debugger. This makes the debugger fairly useless.

I'm not sure what changes occurred to break this process. I know debugging worked fine when I left (rev571).

This is currently a week of final exams for me, so I can't really help until this coming weekend. If 45* or another wants to look into this, here is how I suggest they tackle the problem:

Load revision 571 of RAND, build a fresh debug dll, copy that into the mod, and start a new game, and set a breakpoint at the beginning of "void CvGame::doTurn()", which should cause the debugger to pause at each turn. If that works, we know the revision is good. (I highly recommend you use windowed mode while using the debugger, otherwise alt-tab gets annoying)

Then preform a binary search on the revisions since then. Revision 635 is about half way between now and then. Try and see if debugging works there. If so, check at the half-way point between 635 and 700. If not, check the half-way point between 571 and 635. It should only take 5-10 attempts to find the revision that breaks it. Once we determine that, we can figure out where to go from there.

 

[45°38'N-13°47'E]

Great! I'm gonna try it right away. Only problem might be that I've released in the past some revisions which included a lot of changes from C2C, so if we pinpoint the problematic revision we might need time to find where the problem is in that revision (which included dozens of C2C revisions) but I think I'm able to do it. I'll let you know. Thank you for your advice Afforess.

This is currently a week of final exams for me, so I can't really help until this coming weekend.

All the best for your exams.

 

[Afforess]

Great! I'm gonna try it right away. Only problem might be that I've released in the past some revisions which included a lot of changes from C2C, so if we pinpoint the problematic revision we might need time to find where the problem is in that revision (which included dozens of C2C revisions) but I think I'm able to do it. I'll let you know. Thank you for your advice Afforess.

I figure once we narrow it down, we can simply start removing the changes piecemeal to find the issue.

You should first make sure you:

1.) Generate and use Debug DLL for 571
2.) Run the mod and see how the debugger is "supposed" to work. If you get confused or lost, post here and I can try and walk through it.

Also the "asset" windows that occasionally appear when running the debug dll - when you have the debugger attached, you are able to hit "debug" and jump to the code. Try that once or twice.

 

[45°38'N-13°47'E]

I figure once we narrow it down, we can simply start removing the changes piecemeal to find the issue.

You should first make sure you:

1.) Generate and use Debug DLL for 571
2.) Run the mod and see how the debugger is "supposed" to work. If you get confused or lost, post here and I can try and walk through it.

Also the "asset" windows that occasionally appear when running the debug dll - when you have the debugger attached, you are able to hit "debug" and jump to the code. Try that once or twice.

Mmmm, I don't know why if I set a breakpoint as you suggested the game doesn't stop. But using rev571 I get another debug error right when starting the game, so that's fine for the moment, I can try if debugging works. Problem is that if I debug that stop, it crashes instantly. So probably the problem started earlier. There are earlier changes that were imported from C2C by Koshling when he worked on AND. I'll see if I can understand where it all started.

 

[Afforess]

Mmmm, I don't know why if I set a breakpoint as you suggested the game doesn't stop. But using rev571 I get another debug error right when starting the game, so that's fine for the moment, I can try if debugging works. Problem is that if I debug that stop, it crashes instantly. So probably the problem started earlier. There are earlier changes that were imported from C2C by Koshling when he worked on AND. I'll see if I can understand where it all started.

Make sure when you get an assert, and you hit, "debug", you already have the debugger attached. If not, it will crash.

 

[alberts8]

This thread is meant mainly for 45* and myself, and anyone else familiar with the SDK and Visual Studio.

So what I have discovered coming back to RAND 2 is that I can't do any real time debugging with the Debug DLL. When the debug DLL is built, it doesn't include many optimizations made in the release DLLs and includes debugging symbols, which allow real-time inspection of the code.

Normally, to debug BTS, you build a debug DLL, replace the existing DLL in the mod, and launch the game. Once the game starts loading (either XML or at the main menu, both work) you can use the Visual Studio option to attach a debugger to a process, and select the Civ4BeyondTheSword.exe to debug. While attached, you can set breakpoints, which will pause the game and let you debug, and the game will jump to code if an exception is thrown (normally an exception causes the game to crash). I first thought my setup was to blame. I was using Visual Studio 2008 Express, but I went and installed Visual Studio 2013 Ultimate Edition (I have the license key, yay) and set it up to build civ4 DLL's. It has exactly the same problem.

So right now when I attach Visual Studio to the process, I see the normal debug window console output. But if I attempt to set a breakpoint and debug, or encounter an exception, the game crashes immediately, without jumping to the debugger. This makes the debugger fairly useless.

I'm not sure what changes occurred to break this process. I know debugging worked fine when I left (rev571).

This is currently a week of final exams for me, so I can't really help until this coming weekend. If 45* or another wants to look into this, here is how I suggest they tackle the problem:

Load revision 571 of RAND, build a fresh debug dll, copy that into the mod, and start a new game, and set a breakpoint at the beginning of "void CvGame::doTurn()", which should cause the debugger to pause at each turn. If that works, we know the revision is good. (I highly recommend you use windowed mode while using the debugger, otherwise alt-tab gets annoying)

Then preform a binary search on the revisions since then. Revision 635 is about half way between now and then. Try and see if debugging works there. If so, check at the half-way point between 635 and 700. If not, check the half-way point between 571 and 635. It should only take 5-10 attempts to find the revision that breaks it. Once we determine that, we can figure out where to go from there.

I just tried this with the last svn and Visual Studio 2012. It works here it breaks at breakpoints and then hitting debug in the "assert" windows.

 

[Afforess]

I just tried this with the last svn and Visual Studio 2012. It works here it breaks at breakpoints and then hitting debug in the "assert" windows.

Really? That makes me wonder more about my setup. Any chance you can post a screenshot?

Regarding the project, are you loading the VS Project file in the SVN sources folder? How did you set up the project for the SDK?

 

[alberts8]

I used my c2c build setup.

1. I opened the VS Project file.
2. Edited the paths in the makefile.
3. Built the dll.
4. Put the dll and pdb into the assets dir.
5. Started the game with ""C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe" mod=\Rise of Mankind - A New Dawn" and attached the debugger.

 

[Afforess]

Hm, that is exactly how I do it, except for step 5. Before I came back, I had the DVD version of Civ4BTS, but I lost the disks and snagged the set of games for $5 on steam. So now I am launching from Steam. I wonder if that is causing issues.

I'll try to launch the game exe without steam in a bit.

 

[Afforess]

Okay, steam is the cause. Even starting the EXE without steam did not resolve it. I "acquired" a DVD copy of the game, and used the exact same mod folder & Debug DLL's and debugging works fine.

I noticed the EXE's are different size for steam and the original game. The original game has an EXE 11.8mb, the steam version, 12.2mb. I wonder what specifically breaks the SDK.

 

[Thunderbrd]

I use a NoCDKey exe and that may differ as well but it hasn't caused any issues for me. We DID have someone who was using steam try to get the debug working and seemed to be having epic trouble with it to the point I think he gave up. This certainly explains that!

 

[45°38'N-13°47'E]

Well, it seems like it's working now. Another reason to hate steam.

 

[Afforess]

Well, it seems like it's working now. Another reason to hate steam.

Eh, I blame Fraxis for this one. Fraxis are the ones with the source code, only they could make changes to the EXE. Clearly they took shortcuts.

 

[AbsintheRed]

Sry to hijack the thread, but it's somewhat connected:
Do you guys debug Civ IV with crash dump files? If so, how?
Or is it always preferred to debug the game with a debug dll instead?

When I try to handle BtS-made .dmp files in Visual Studio, I can add the CvGameCoreDLL.dll, the symbol (.pdb) and the source files for it.
But VS always wants to have to symbol files for the Civ4BeyondSword.exe too, so I'm kinda stuck here.

 

[dbkblk]

I don't know about pdb files, but we usually grab a faulty savegame and reproduce the bug in debug mode to get to the wrong code. That said, if you find a more efficient way to do that, you're welcome
Maybe you should need to produce a debug version of the DLL first to handle PDB ?

 

[AbsintheRed]

I don't know about pdb files, but we usually grab a faulty savegame and reproduce the bug in debug mode to get to the wrong code. That said, if you find a more efficient way to do that, you're welcome
Maybe you should need to produce a debug version of the DLL first to handle PDB ?

.pdb files are for the symbols
It comes both with a release dll and a debug dll, if compiled correctly

Dump files (.dmp) can created by Civ IV itself, and it should be possible to check them with a normal .dll, if the .pdb is attached
Nevertheless I cannot debug those dump files, neither with a final release dll+pdb, nor with a debug dll+pdb, as it wants pdb for the .exe too
I'm sure it's possible, so it's probably a silly mistake on my end, but I'm not sure what to do with it, as I never debugged dump files before

I'm familiar with compiling and using a debug dll, but dump files have an advantage (theoretically, that is if I can run them ), as they already contain information about the bug itself.
So there would be no need to reproduce the same bug separately, with a new .dll

 

[dbkblk]

I've already heard about the theory but never tried to use this actually. You look quite experienced with those process, do you have some will to develop the mod ?

 

[AbsintheRed]

I've already heard about the theory but never tried to use this actually. You look quite experienced with those process, do you have some will to develop the mod ?

Oh, thank you for the offer, it's flattering
But I already have enough on my hands with RFC Europe, so I have to say no, at least for now.
AND is a great mod, with some serious improvements over BtS. Especially the under-the-surface adjustments in the dll and in the base game mechanics.
Keep up the great work!

 

[Nightinggale]

Eh, I blame Fraxis for this one. Fraxis are the ones with the source code, only they could make changes to the EXE. Clearly they took shortcuts.

The issue appears to be something completely different. Steam has an anti-cheating system. It will not allow trainers to inject extra money or whatever into games as this would kill the idea with the reward stuff you can earn (500 kills and whatever). They inject this anti-cheat system into all their exe files and it is intended to crash the game if somebody cheats. However they can't tell the different between a cheater or a debugger and assumes the debugging to cheat.

I'm not sure what to say about it as it actually works as intended and the reason has nothing to do with lazy coders or coding shortcuts. However clearly steam isn't modder friendly.

Dump files (.dmp) can created by Civ IV itself, and it should be possible to check them with a normal .dll, if the .pdb is attached
Nevertheless I cannot debug those dump files, neither with a final release dll+pdb, nor with a debug dll+pdb, as it wants pdb for the .exe too

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

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.

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.

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

 

[Combat Wombat]

The issue appears to be something completely different. Steam has an anti-cheating system. It will not allow trainers to inject extra money or whatever into games as this would kill the idea with the reward stuff you can earn (500 kills and whatever). They inject this anti-cheat system into all their exe files and it is intended to crash the game if somebody cheats. However they can't tell the different between a cheater or a debugger and assumes the debugging to cheat.

I'm not sure what to say about it as it actually works as intended and the reason has nothing to do with lazy coders or coding shortcuts. However clearly steam isn't modder friendly.

Oh man so much wrong here. Why do people spread such ignorance?

A. Civ4 has no VAC protection on Steam. Also that isn't even the way VAC works. VAC is purely external to the game and watches for modified assets/memory for cheat injections. Also VAC doesn't crash games it just adds you to a list to be banned.

B. The changes to the .exe are adding Steam DRM, preventing the .exe from running except from a Steam client.

C. The developer/publisher decides whether to have DRM not Valve. Lots of games have none at all.

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