-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Crash] Unknown/Strange crash in Chrome.dll (AccessViolation). while calling win32 CreateWindowExW #355
Comments
UPD: @win32ss, I have seen additional pdb's you have uploaded here Can you upload this #338 ?, as we discussed at the bottom, so I will ty. |
UPD: got the SallStack using new updated PDB. Pdb is ok for now. Callstack is near some as I got before for v121-dbg I see some garbage, called from function. at 0x0211e200 : Why the code crashes, while calling Win32 API CreateWindowExW() ?? |
I'm got more precise results:
But instead called some garbage from 0x0211e200... So "window" pointer or its fields have garbage. I can't see fields contents, because VS2010 dont show it. (Dont know about other VS versions (later), they are not compatible w/remote debug on XP) |
Any idea if these failed calls came from WM_NCCREATE or not? I wonder if the WindowUserData got overwritten with garbage after the window was created, as the WindowImpl is inherited by HWNDMessageHandler, and the pointer to that instance of WindowImpl is passed to CreateWindowExW as the lParam value, which is then set as WindowUserData on the WM_NCCREATE message. Is there anything that could be hooking the windows and potentially overwriting the WindowUserData? |
The bug was found by me and fixed. The bug was in my own (and very old) application layer compatibility dll from 2009 year for DWMAPI.dll for XP. |
Unknown crash in Chrome.dll after starting and clicking on GUI interface with mouse.
AccessViolation at some location.
Its happened with latest v122."Hotfix2"
But earler versions -- v121, v122 -- same situation.
As I mentioned here #338, its need to provide stripped-down pdb file while linking. Or with postrprocess pdbcopy tool.
To debug crashes on XP x86 machines. (and elsewhere).
We just cant use this huge pdb file to debug. And to view Callstack at least.
But there are no reaction.
The issue described here #323 was "fixed", But some wrong way. Because now it dont creates CrashDump's at all. And creates no logs at all. :) :)
This is CallStack from VisualStudio, where we can't see Function names, without adequate PDB :
The text was updated successfully, but these errors were encountered: