Ok, here is what I am doing. I run steam. Then I run VC++ and launch hl.exe from there with a break point in ClientPrecache. When it breaks I look in the thread list, there are 18 threads many of them with references to "STEAM!". I continue the game and wait till it gets to the stage where it hangs. Then I switch to VC++ (which results in the CPU usage reducing from 100% to 0% before I can check anything) and check the thread list, now 21 threads, assuming the game thread is in the same position I make the thread active and step through the code.
The thread for the game seems to have three main states:
NTDLL! [EMAIL PROTECTED] + 3 bytes USER32! [EMAIL PROTECTED] + 57 bytes USER32! [EMAIL PROTECTED] + 405 bytes HL! 01db511c() 558b144d()
and
NTDLL! [EMAIL PROTECTED] + 3 bytes USER32! [EMAIL PROTECTED] address 0x77e14735 USER32! [EMAIL PROTECTED] + 405 bytes HL! 01db511c() 558b144d()
which both appear twice for each:
NTDLL! [EMAIL PROTECTED] + 3 bytes USER32! [EMAIL PROTECTED] address 0x77e36e56 USER32! [EMAIL PROTECTED] + 405 bytes HL! 01db511c() 558b144d()
Hold down shift and F11 and watch the CPU raise to 50% usage and the thread call list switch between those three states.
... at least I'm learning more about debugging under windows :)
Jeff.
Taylor Sherman wrote:
Actually, to clear some things up:
- there aren't any "Steam threads" in the game process, they all exist in the Steam.exe process. Only the game threads exist in hl.exe (Steam commands get sent to the Steam.exe process and handled there).
- Jeff, I'm not sure what you mean. It should be fine attaching to a running game that was launched through Steam. Debugger-wise it shouldn't be much different than it was pre-Steam.
Anyway, when you hit "break" in the debugger, whatever thread it ends up in, you can switch to any of the other threads which are running in that process. In VC6 I believe it is Debug -> Threads. In VC7 there is a debugger window that you can open and select thread contexts from. In an hl.exe instance, there should be at most two threads, both "game" threads (the main game thread and one loading resources - I'm not sure if that latter one is still active).
Taylor
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Codiac Sent: Wednesday, December 24, 2003 11:25 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Registry values for installs and other things
lol, you can't actually attach to a running Steam game, because when you switch windows to the debugger Steam switches to AppActive: not active and the game thread is paused.
This will even prevent you from debugging the game thread within VC++ unless you set a break point. That is, switching to VC++ and selecting Break will not get you the game thread.
It is of course very hard to set a _usefully_ located break point unless you know what is actually happening during the Verifying Resources stage.
i.e. Verifying Resources seems to be run after all map objects have spawned and some time after StartFrame is called for the second time. Long enough after that many minutes of stepping through the code does not help.
Break points in the game rules think functions do no work.
Can you give me a clue as to what Verifying Resources does and what parts of the SDK it uses?
Jeff.
Alfred Reynolds wrote:
Check the other threads, it looks like you broke into one of the Steam
threads (which won't effect you).
Have you tried putting a breakpoint at the start of your mod code and stepping from there?
- Alfred
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
