This guy Alfred Reynolds has a point. Since you are using VC ++ user mode debugger, I assumed the thread you broke into was part of your code.
Now that I am learning more about HL coding (remember I sad I was green as a green tea) it is clearer to me. When you launched your debuger ( I assume the one that came with VC++) it was debuging the entire game proccess. I forgot that it's the client dll that you are writing and are interested in which as I understand it is called by the game engine? or another Dll? The stack dump for the thread you dumped could be a wild goose chase. I guess what I am asking the forum is what calls the client dll? How can one set break point for the init functions of the client dll? Is there any way to identify the thread that will call this dll? Can anyone elaborate on this so I can drink regular tea? ----- Original Message ----- From: "K. Mike Bradley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 23, 2003 10:20 PM Subject: Re: [hlcoders] Registry values for installs and other things > I would be worried if I found a strange process on my development PC > (ie:PDM.exe) > > > I have no idea what PDM is. None of the functions on the stack are from > > my mod. My mod is compiled with symbols for both client and server. > > > Yes none of those functions are from your Mod code but they, no doubt, are > the result of the calls made by the game engine. > > Any Win32 user mode process that calls an API like ... CreateFile() (which > happens to exist in kernel32.dll) will eventually call a stub function in > NTDLL.dll (the user mode interface to the native NT API) that then results > in a kernel mode call, to service the request, via the file I/O driver, and > then the hall.dll. > > So these functions on the stack, so to speak, are from your code. (I assume > you aren't running another app at the same time). > > > The symbol files for the engine would be useful. I am not hopefull of > > seeing them though ... Unless I win the big Christmas lotto draw and buy > > a source license :) > Microsoft has released symbol files for all Win32 images as well as native > NT API. > This is not releasing the source at all and posess little risk to Valve. > Valve should be freindly here I think and give it up. > > > Read this: > http://www.microsoft.com/mspress/books/sampchap/2345a.asp > > Then read this which is more to the point : > http://www.microsoft.com/mspress/books/sampchap/2345b.asp > > I think a thread in the game engine is waiting for a kernel object to become > signaled. > > At the bottom of the second page that I referenced, it says this: > > ============================================================================ > ===== > In reality, the algorithm Microsoft uses is simply the popular "first in, > first out" scheme. The thread that has waited the longest for an object gets > the object. However, actions can occur in the system that alter this > behavior, making it less predictable. This is why Microsoft doesn't > explicitly state how the algorithm works. One such action is a thread > getting suspended. If a thread waits for an object and then the thread is > suspended, the system forgets that the thread is waiting for the object. > This is a feature because there is no reason to schedule a suspended thread. > When the thread is later resumed, the system thinks that the thread just > started waiting on the object. > > While you debug a process, all threads within that process are suspended > when breakpoints are hit. So debugging a process makes the "first in, first > out" algorithm highly unpredictable because threads are frequently suspended > and resumed. > > ============================================================================ > ====== > > This scares me. It means that the thread or threads that are suspended, (and > will be woken up, when the object or objects become signaled), under some > conditions, could result in a situation as you describe where the objects > are signaled (or ready) and the thread stalls. > > Sorry I can't be of more help. > > Something really weird is going on here and I think your code has uncovered > (inadvertantly) this weird phenominon. > > This is the type of situation where a coder's code (which has no compile > errors) causes a problem in the underlying OS API's and it is one of the > most frustrating things that can happen. > > Bottom line is to step back for a moment .. go over your code from stem to > stern ... look for anything that is not right. > > What code has changed since it ran ok ? Look back at your previous code > changes to see if you can get it back to working, then you will have > narrowed it down. > > Good luck you will need it. > > > > > ----- Original Message ----- > From: "Codiac" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 23, 2003 8:35 PM > Subject: Re: [hlcoders] Registry values for installs and other things > > > > I have no idea what PDM is. None of the functions on the stack are from > > my mod. My mod is compiled with symbols for both client and server. > > > > Google trolling seems to indicate that WaitForMultipleObjects can be > > linked to race conditions, which seems to be the situation here. > > > > Unfortunately I can't figure out what is causing the race conmdition. > > > > The symbol files for the engine would be useful. I am not hopefull of > > seeing them though ... Unless I win the big Christmas lotto draw and buy > > a source license :) > > > > Jeff. > > > > K. Mike Bradley wrote: > > > Yes debuging is fun eh? > > > > > > The object now is to find out where to set a break point so that you can > > > single step perhaps into the user mode calls. > > > > > > The wait for multiple objects looks suspicious. > > > > > > I can't tell if these multiple objects (being waited on), are newly > created? > > > Or are failing (hanging) when created. > > > > > > I, alas, am not a mod coder and have only just started looking into the > SDK. > > > > > > What is the PDM process? is this your mod code? > > > > > > You should be able to generate symbols at compile time for the client > dll. > > > I wonder if Valve offers symbols for their part of the code so one may > trace > > > into calls there ??? > > > > > > > > > Anyone from Valve have an answer? > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "Codiac" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Tuesday, December 23, 2003 2:11 AM > > > Subject: Re: [hlcoders] Registry values for installs and other things > > > > > > > > > > > >>Thanks, but it seems like I got the little buggers installed ok :) > > >> > > >>K. Mike Bradley wrote: > > >> > > >> > It's been a while since I set up symbols in Visual studio (VC++) 6 > SP5 > > >> > but let me know how it goes. I could look up my old notes. > > >> > > > >> > > >>This is what the stack has to say now: > > >> > > >>NTDLL! [EMAIL PROTECTED] + 11 bytes > > >>KERNEL32! [EMAIL PROTECTED] + 158 bytes > > >>USER32! [EMAIL PROTECTED] + 224 bytes > > >>USER32! [EMAIL PROTECTED] + 29 bytes > > >>PDM! 4a00888c() > > >>PDM! 4a008aa5() > > >>PDM! 4a008a29() > > >>KERNEL32! [EMAIL PROTECTED] + 82 bytes > > >>565308ec() > > >> > > >>Still leaves me with no idea wtf is going on :P > > >> > > >>Jeff. > > >> > > >> > > >>_______________________________________________ > > >>To unsubscribe, edit your list preferences, or view the list archives, > > > > > > please visit: > > > > > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > > > > > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > > > -- > > > > Jeff "Codiac" Fearn > > ----------------------------------------------------------------- > > Lead Coder, Web Master, Server Administrator for SWARM > > http://swarm.hlgaming.com > > > > Coder for Wizard Wars > > http://www.planethalflife.com/wizardwars/ > > ----------------------------------------------------------------- > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
