i'll edit this post from time to time to update it untill it's finished. Worker Thread and Service Agent execution. If an exception is thrown from the SA, the exceeption is logged (using the Exception management mechanism). The default exception publisher logs to System Event log. This is because the worker thread has a try-catch inside the thread proc. And this makes that the while loop inside the thread procedure to continue. The Worker thread has a serviceAgentRequest memeber variable which is set \ cleared to null on SA creation execution \ SA execution returns. Worker thred checks for this variable at the loop begin and resubmits the request (it wont look at the requests queue). So, when an exception is thrown from a SA during execution, the SA will be resubmitted indefinetely until the SAMonitor aborts the worker thread. Regarding the SAMonitor: Note that in the case of the exeception thrown from SA, the SAMonitor is called to add the worker thread at each

Due to a security patch Windows has restricted access to a CHM. More info here: http://support.microsoft.com/kb/896358. The attached reg script fixes one of the 4 problems described in the KB. It works for most of the CHM files. Here is the file. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions] "MaxAllowedZone"=dword:00000004

Each time when you use a win32 API which uses a HANDLE remember that the handle Must be valid (not closed). It is important to understand the concepts of the handle being signaled and being closed. Signaled state refers to the handle state. It can be signaled or unsignaled. Wait functions for example, like WaitForSingleObject, block current thread until the object gets signaled. A handle is said to be closed when its reference count reaches zero value. When this happens the handle is closed and doing any waiting on it is error prone. A handle is a pointer on an object. Wait functions check the state of the object, hence it is a must that the handler (the pointer) is valid. Otherwise, waiting functions wont work properly (while waiting on an invalid handle, you might wait indefinetly). One example of bogus use is with MFC AfxBeginThread function. Its default behaviour is to auto 'delete' the thread, i.e to close its handle. Its bad to use the returned handle after the thread is