Open GoogleCodeExporter opened 8 years ago
O, i am wrong in the previous post about error code, the actual return code of
registerwindowex is ERROR_CLASS_ALREADY_EXISTS(1410). So the reason is obvious.
Original comment by xizhi...@gmail.com
on 16 Feb 2011 at 3:38
interesting; I'll have to see if I can track this down. Do you have a test
page that makes it easy to reproduce?
Original comment by taxilian
on 16 Feb 2011 at 4:28
I think i know why.
The microsoft doc
(http://msdn.microsoft.com/en-us/library/ms633574%28v=vs.85%29.aspx)
says:
The executable or DLL that registered the class is the owner of the class. The
system determines class ownership from the hInstance member of the WNDCLASSEX
structure passed to the RegisterClassEx function when the class is registered.
For DLLs, the hInstance member must be the handle to the .dll instance.
The class is not destroyed when the .dll that owns it is unloaded. Therefore,
if the system calls the window procedure for a window of that class, it will
cause an access violation, because the .dll containing the window procedure is
no longer in memory. The process must destroy all windows using the class
before the .dll is unloaded and call the UnregisterClass function.
--------------------------
Original comment by xizhi...@gmail.com
on 16 Feb 2011 at 7:25
The point is that for some reason, the window class is not unregistered.
I have submitted a patch to fix this issue.
---------------------------
if (!(clsAtom = ::RegisterClassEx(&wc))) {
err = ::GetLastError();
---here catch the error and do not throw-> if(err !=
ERROR_CLASS_ALREADY_EXISTS) // fixed an IE Dll unload problem #issue 145
{
throw std::runtime_error("Could not register window class");
}
}
}
// Step 2: Creating the Window
HWND messageWin = CreateWindowEx(
WS_OVERLAPPED,
----here do not use atom, use string instead -> wszClassName, //
(LPCWSTR)clsAtom, this fixed a bug when clsAtom is not available due to
ERROR_CLASS_ALREADY_EXISTS.
wszWinName,
0,
0, 0, 0, 0,
HWND_MESSAGE, NULL, gInstance, NULL);
Original comment by xizhi...@gmail.com
on 16 Feb 2011 at 7:36
[deleted comment]
I have tested the above fix code and the problem is gone.
The cause perhaps is that when you force close an IE window tab, the dll is
unloaded, but the registered window class is not.
Original comment by xizhi...@gmail.com
on 16 Feb 2011 at 7:40
Fixed as you suggested. Thanks! This will be in RC1.
Original comment by richarda...@gmail.com
on 17 Feb 2011 at 10:52
Original issue reported on code.google.com by
xizhi...@gmail.com
on 16 Feb 2011 at 3:06