[SDK] Using Microsoft Visual C++ 2005 Express Edition

[glider1]

I tried VS2008 under Vista ultimate and concluded that there is something with user rights management that is the problem but I could not prove it. Thanks for the tip to try 2005 first. If I get VS2005 going, will try VS2008 again. Normally something gels once you have a good working base setup. It's like climbing everest with basecamp as VS2005.
Cheers.

 

[Refar]

I tried VS2008 under Vista ultimate and concluded that there is something with user rights management that is the problem but I could not prove it.

This is my suspicion as well.

 

[glider1]

Thanks Fagan and everyone. The PDF guide and makefiles are excellent and your efforts are great as noted by more than 140 downloads.

Tried debugging under XP but it does NOT work. Compiles fine as per normal.

Conditions are:
XP media center edition SP2
BTS 3.17
VS2005 Express SP1
Visual C++ Toolkit 2003
Platform SDK for Windows Server 2003 R2
This forum post #229 makefile and PDF
The three extra libraries as per PDF
Terminal services started and set to manual

The debug output shows no symbols loaded for the DLL and it won't set breakpoints. This exact phenomenon happens on a Vista x64 box running VS2008.

EDIT QUESTION:
Have tried Dresdon's suggested makefile changes post #231 with no luck. This change in reference to the libraries doesn't need a clean rebuild does it? What does it need, just a restart? reboot? double espresso? cigarette's? midnight oil? All of the above??

Cheers

 

[Refar]

Sorry to see it still does not work for you.
Your settings are almost exactly the same as my - i run XP Home SP2 tho. (Does someone know what the exact difference to Media Center Edition are ?)

As you noted before i am quite sure it is something about user/process access settings. Unfortunately i can't tell you exactly waht. Some thoughts... Where is your game (and consequently the Dll) located ? - If it's C:\Program Files\... Windows just loves to restirct access to it... Otherwise - are the Dll, the Symbol file and the Process accessible for the debugging process....

Another thing to concider... Have you tried to compile/debug something completely different - say the good old "Hello World" or something. It might be easier to figure out where the trouble comes from on a simplier subject.

 

[Dresden]

EDIT QUESTION:
Have tried Dresdon's suggested makefile changes post #231 with no luck. This change in reference to the libraries doesn't need a clean rebuild does it? What does it need, just a restart? reboot? double espresso? cigarette's? midnight oil? All of the above??

The change was a linked library on the final step so simply deleting the current CvGameCoreDLL.dll and then doing a normal rebuild should work; you don't need a clean rebuild. However, I don't think that's your problem as that Makefile change is a way to avoid the errors about a missing MSVCP71D.dll and/or Python issues. If BTS launches OK for you with the debug DLL installed then you probably don't have that problem.

Are you launching BTS separately? (I think you have to, at least I do)
Can you attach to the running process ok?

 

[glider1]

@Dresdon and Refar

I can now debug.

You may shoot me. After the problematic times with Vista and thus switching to XP, I have forgotton the basic's of what I was doing on Vista. That is to copy the big mother debug DLL into the BTS assets folder under program files (backing up the original DLL). Once that was done, VS2005 attached and loaded the DLL symbol database under XP without hesitation according to the PDF instructions.

For the first time EVER....I can see the machine working from within and breakpoint it.

Cheers and thank you

 

[glider1]

@Dresdon and Refar
I can now debug.

Well, kinda.

Debug is working except I think I have a similar issue as Dresdon regarding the missing MSVCP71D.dll library. I have had to modify the makefile as per Dresdon's changes, in order to get debugging happening at all.

However there is an annoying Fassert dialog which I have attached here. If you press "ignore always", you get away with it and can continue debugging, until at some point an Fassert dialog popup's that cannot be recovered from. The debugger then points to some inline code before proceeding to the infamous CTD.

Is this happening to any of you debuggerers? Where can I get that darnit library or is there an alternative?
Cheers.

 

[Dresden]

Asserts are part of the SDK which are enabled in debug builds (or if you manually enable them). They identify problems where a function expects a certain value or range of values but has instead been passed something else; usually it indicates trouble that needs to be corrected. Are you getting them on a modified DLL or on an unmodified recompile?

 

[glider1]

Thanks Dresdon. I'm getting them from a modified DLL (RevolutionDCM mod). It did not seem to happen in the unmodified base recompile. However if I run the mod using Final_Release, all is well. So it appears you are correct that it is a debug issue of some kind.
Cheers.

 

[Dresden]

That makes sense then. Generally those are problems in the mod; they aren't limited to the SDK as something wrong in the Python, XML, etc. could be the initial trigger, but the SDK is noticing them and reporting them when you use the debug DLL. They could be inconsequential or they could be indicators of an impending crash; you'll have to determine the severity when you debug.

 

[Daryl95]

How do I open and edit .dll files for downloaded mods.

 

[Dresden]

You don't. You open and edit the source code (assuming it is supplied with the mod) and then recompile a new DLL if you make any changes.

 

[Daryl95]

Where can I get the source code a mod if it doesn't come with the mod?

 

[Refar]

That you should be asking the creators of the mod.

 

[glider1]

@Refar and Dresdon and Fagan
Hope you are having a good Christmas and thanks for your help to get me debugging through 2008. Just an update that I have now successfully reached the top of the debugging freeware mountain under V64 in this configuration:
1) Vista Ultimate x64
2) Microsoft Visual C++ 2008 Express Edition
3) Microsoft Visual C++ Toolkit 2003
4) Platform SDK v6.0A
5) BTS 3.17

It worked first go and is no different in procedure to VC 2005 running XP except that you have to restart VC 2008 when you want to attach to the process because Vista requires administrator privileges. VC 2008 prompts to do this so it is no drama. Why I could not get it going six months ago, forcing me to switch to XP for debugging, remains a mystery. I suspect I got confused at some point or that an automated "vista update" slipped through the net during the ensuing period, that fixes privileges issues under x64 on my install.

The only step that beginners should not forget is to replace the game DLL with the big debug DLL you have compiled. Preferably debug a mod not the base game, so that you do not have to replace the original BTS DLL. There are more sophisticated ways to debug so that you do not have to manually replace the DLL each time you do a debug compile, but just keep it simple for now.

If anyone wants more help, just post here and I will assist as best I can.
Cheers.

 

[Jean Elcard]

Is there a way to attach the debugger to a running process automatically?

At the moment it's more or less a contest between me and my computer, whether I am fast enough to manually attach the debugger to the civ process to catch an early error or not. There has to be way, but I couldn't figure out how to do it. Any ideas?

I could place an always triggering Assert to make the game stop early for a moment, but I rather would'nt need to do this.

 

[glider1]

Is there a way to attach the debugger to a running process automatically?

I don't have an answer, but a question. If you load up BTS with your mod of interest, so that it arrives at the opening menu for BTS with no game loaded just the mod, is this not a sufficient point at which to attach to the process? Perhaps not, because parts of the modified CvGameCoreDLL execute before you can attach?

Cheers.

 

[Kalimakhus]

Is there a way to attach the debugger to a running process automatically?

You can actually run BTS from within Visual Studio and load the mod automatically. Also if you set break points BTS will continue executing untill it hits the first one of them then the debugger would take over and allow you to inspect variable values and step through the code one statement at time.
I haven't done it with BTS but i did it numerous times with other DLLs.

The way to do it is:
In the DLL build options you will find a text box for the executable the DLL is supposed to work with. In this box enter the full path to the BTS exe file. There is also another box for command line arguments you can put "mod=\ModName" there. For debugging you need to select run (or F5 as far as I remember). This should cause BTS to start.

You need to remember setting BTS to the windowed mode, but I guess you already do that.

 

[xienwolf]

Cool, that does work nicely, but it still needs something to stop the processing of the game trying to load so you can run it step-by-step. Any way to force it to break process as soon as it hits something which exists in the DLL?

 

[Kalimakhus]

@xienwolf
Add a breakpoint within the DLL's code. In any .cpp file choose the statement right-click and select add breakpoint or something similar. It should stop execution once it hits this line of code. Also if there is a problem it will stop at the code seemingly causing it.