Based on this link, I am creating Windows Processing Monitoring and Windows Service Monitoring DLLs that are to be called by the main application and run them in thread(using boost::thread) to get the data asynchronously. Consider that these both dll are run by my application. I get the error Failed to initialize security. Error code = 0x80010119 for one of my app. And also when stopping the threads for these dll, CoUninitialize is called in both of them. Here I get a crash. It might be because the CoUninitialize in latter thread might attempt to clear memory that was cleared by former thread.
If so, how can I check whether the CoUninitialize in one thread was successful so that I would not call it in another thread.
CoUninitialize is a part of COM library, WMI can use COM interface, but has nothing to do with its initialization or disposal. Don't call CoUninitialize twice within one process. Note, that both of your DLL's probably share application context and are executed within it.
"how can I check whether the CoUninitialize in one thread was successful so that I would not call it in another thread."
That tells me your error, but it's not in CoUninitialize. You are assuming that CoUninitialize is process-wide. In reality, CoUninitialize mirrors CoInitializeEx, and that should have de done on every thread. So your crash is almost certainly caused by a CoInitializeEx on one thread and the CoUninitialize on another thread.
The fix is to do CoInitializeEx on both threads, and CoUninitialize also on both threads.
Related
I'm getting some DLL_THREAD_ATTACH notifications in my COM DLL, but none from the app pool worker threads, from which my COM DLL is actually invoked.
Subsequently, calls to the DLL initiated from IIS arrive on threads for which DLL_THREAD_ATTACH was never called.
Only the first thread of the app pool is notified when the DLL is attached to dllhost.exe (via DLL_PROCESS_ATTACH).
Is this a defect or a feature, and is there any workaround?
DLL_THREAD_ATTACH is often misunderstood. You don't give enough information, but it is likely that your problem is due to this :
From the MSDN documentation, emphasis mine :
DLL_THREAD_ATTACH | The current process is creating a new thread.
On the same page :
There are cases in which the entry-point function is called for a terminating thread even if the entry-point function was never called with DLL_THREAD_ATTACH for the thread:
The thread was the initial thread in the process, so the system called the entry-point function with the DLL_PROCESS_ATTACH value.
The thread was already running when a call to the LoadLibrary function was made, so the system never called the entry-point function for it.
To work around this, you can either manually enumerate every thread of a process when DLL_PROCESS_ATTACH. You can also do a first time init when your DLL functions are invoked on a new thread. Obviously, you can also create the threads AFTER the DLL is loaded, if it is possible.
Unfortunately, MSDN is not clear enough with it. I'm writing a program which uses a global hook, and I'm worrying about what would happen if the program terminates abnormally (crashes, killed by user, etc).
Does Windows automatically unhook global hooks installed by a process when the process terminates?
If not, is it possible to call UnhookWindowsHookEx() in another process to release the hook? (I'm thinking of doing this in a hooked thread, if it detects that the installer process is dead.)
If the answers were no and no, isn't it dangerous to leave a global hook active when the installer process is terminated? What are the standard methods of dealing with this situation?
I've read in MSDN that UnhookWindowsHookEx() doesn't free the dll loaded in other processes, but it doesn't say when will the dll be freed. This article in CodeProject seems to suggest that the dll is unmapped (in the respective process) when the first message arrives at the hooked thread, so it's about right after the UnhookWindowsHookEx() call. Is it true?
Thank you.
Yes, when a process terminates the system cleans up after it -- all handles are closed implicitly.
No, it's not, and you don't need to anyway.
(It's Yes and no not no and no)
I don't see why there's a DLL loaded in another process involved here. (EDIT: I was originally thinking of a systemwide hook such as CBTProc -- if your hook is per-process that might be different) If you're dealing with something like the link indicated in #Hans' comment, whereby you've injected your own DLL into the target process, then you should put functionality to unload the hook inside your DLL, not tie it's correct operation to your application. (I.e. if sending the message back to your application fails inside the DLL, then your DLL should decide to unload itself) /EDIT When a DLL is loaded inside another process it's up to that process to do the freeing.
If your process dies, UnhookWindowsHookEx is called implicitly and your hooks are removed. The .dll is unloaded by the message processing code after a new message is received. Therefore some background processes which almost never receive any messages, may still keep the library locked long after your hook was removed. Broadcasting a WM_NULL message usually helps. I like sending it a few times after unhooking.
SendNotifyMessage(HWND_BROADCAST, WM_NULL, 0, 0);
Like in the above graph,all other threads will automatically exit once the main thread is dead.
Is it possible to create a thread that never dies?
You can, but you probably shouldn't; it will just end up confusing people. Here is a good explanation of how this works with Win32 and the CRT.
You can end the main() function's thread without returning from main() by calling ExitThread() on it. This will end your main thread, but the CRT shutdown code that comes after main() will not be executed, and thus, ExitProcess() will not be called, and all your other threads will continue to live on.
Although in this case, you must take care of ending all the other threads correctly. The process will not terminate while there is at least one thread that is not "background".
If main() is careful not to call ExitProcess() (or whatever it's called that happens when main returns) until all threads have terminated, that is easily done. Just don't exit main until it's done.
Not really. The CRT startup code calls main(), then calls exit(). That terminates the program, regardless of any other threads.
You would have to prevent main() from returning. Normally done with WaitForSingleObject() on the thread handle.
In this specific case, if you see the threads still running when you trace through main's return then you forgot to release/close the Win32 resource you are using.
It looks like it might not be possible as you can see from the other answers. The question is why would you want to do this ? By doing this you are going against the intended design of the OS.
If you look at this : http://msdn.microsoft.com/en-us/library/ms684841(VS.85).aspx
You will see that a Thread is meant to execute within the context of a process and that in turn a fiber is intended to operate withing the context of a thread.
By violating these premises you will potentially end up having issues with future operating system upgrades and your code will be brittle.
Why do you not spawn another process and keep it in the background ? That way you can terminate your original process as desired, Your users will still be able to terminate the spawned process if they desire.
Can an unreleased COM pointer to an external process (still alive) cause that process to hang on destruction?
Even with TerminateProcess called on it?
Process A has a COM interface pointer reference to Process B, now Process B issues a TerminateProcess on A, if some COM interface pointer to Process B in Process A is not released properly, could it be that the process hangs on termination?
I want to know as I have a project where a child process hangs on killing, even though TerminateProcess is called if the normal close procedure fails. When it hangs on killing, it doesn't just hang itself, but also it's parent process, which is disastrous since this is running in a production environment. So I'm trying to see where there's possibilities of it going wrong.
No. TerminateProcess does just that -- completely destroys the process. Raymond Chen has a few words to say about that....
EDIT: He also has some more detailed articles detailing exactly how process shutdown occurs. It however is not related to TerminateProcess.
Well, yes, it is technically possible for TerminateProcess not to terminate the process. If there's a kernel thread executing an I/O request that never ends then the process cannot exit. Easy to diagnose, you'll see the process in Taskmgr.exe's Processes tab with a handle count of one. Vista had a CancelIo improvement to fix this, I think Raymond talked about that too.
Which is only very remotely associated with COM. Grasping at straws: an out-of-process COM server doesn't deal with TerminateProcess of a client well, Windows cannot automatically call Release() on the interface pointers. It will keep running forever. Until somebody calls TerminateProcess, usually the Windows shutdown code or TaskMgr.exe
Do make sure to edit your question and explain why you even asked it.
Is it okay to register WSACleanup through atExit function ? We have several applications that can terminate at different points in the code so we would like to avoid putting WSACleanup everywhere throughought the code. Curently we call WSAStartup / WSACleanup through DllMain since we have a dll that is used by all these applications. However, Microsoft strictly advices against the use of WSAStartup / WSACleanup via DllMain since this can cause deadlocks. We can move WSAStarup out of DllMain and call this at one point in the code for all applications before they access the Windows sockets library. And, as soon as we call WSAStartup, we would like to use the atExit function to register a call to WSACleanup. Does anyone have any experiences with this approach ? Thanks!
If you have a multi-threaded app and some of the threads are still connected, the applications at the other end may not like the way the connection is terminated. So it is preferable to close down all communication in an ordered way before main() terminates, and when you have done that, you can just as well call WSACleanup.
I agree that the RAII approach is favourable.
However a word of warning: atExit mixed with dlls and handles is broken on windows. Unfortunately this effects RAII too as this is implemented with atExit handlers by the c++ runtime.
The order that atexit handlers are called on windows:
somewhere exit is called or main() goes out of scope
atexit handlers defined in the process are called.
all handles are destroyed.
atexit handlers defined in dlls are called.
It doesn't matter if atexit handlers in dlls are registered before handlers in the process the process handlers are called first and the handles are destroyed before the dll handlers are called. This results in win32 exceptions, when the clean up code is called as all the handles owned by dlls are no longer valid.
This effects code that holds handles to threads, mutexs, files, sockets etc. If they are allocated in a dll then they must be cleaned up before exit is called or not at all.
By the way I am not anti window, if I am wrong or anyone knows any way around this I would love to know as this causes me untold pain in application clean up. I figured this out be debugging exit handling in the c++ runtime, after getting win32 exceptions when applications exit.
I had to remove all calls to exit from my code. I now ensured that no static data in a dll controls a handle. All static handles are controlled by objects that are destructed when main goes out of scope.
Well I think atExit should not be used. You should follow RAII principle of wrapping of initialization and destruction of socket library in a class.