(This is a plug-in that wants to intercept keyboard events that get sent to its host (64-bit), even though the host doesn't provide keyboard events to its plugins the normal way. I do not have the source code of the host, though I do have the source code of the plug-in.)
After the keyboard hook procedure successfully runs and returns, the program crashes. The crash happens inside Windows' ZwCallbackReturn(), executing the syscall instruction. The exception is 0XC0000005 (access violation). The crash only happens if a particular key is pressed which triggers some particular logic.
I am stuck diagnosing this crash and could really use some help. I am sure the problem is in this big chunk of code that's in the hook proc. What I am having trouble with is understanding where the crash occurs and where to basically place the breakpoint to preempt it.
Here's what I tried so far. It is my understanding that the syscall instruction itself doesn't generate the exception: the registers look sane, and I guess the stack would remain the same if it crashed. So I think that after this instruction initiates transition back to the kernel mode, from where the "user callback" (the hook procedure call) had originated, the kernel continues to run just fine. Eventually it should return control back to userland -GetMessage() I presume). Then down the road, I think, the stack gets corrupted and the program crashes. But unfortunately I can't instruct my Visual C++ debugger to break at the first user-mode instruction executed, before the stack is corrupted. I tried installing conditional breakpoints in TranslateMessage() and DispatchMessage(), which are most likely to run right after GetMessage(), but they don't fire between the last good user-mode instruction and the crash.
The crash happened because the keyboard hook procedure was NOT the first in the hook chain. It was called from a previous hook in the hook chain via CallNextHookEx(). And that previous hook was registered by a DLL which got unloaded inside "our" keyboard hook.
Hello,
I am currently trying to use Intel GPA to analyse a Unity, DirectX 11 game.
Unfortunately using Intel GPA on this game makes it crash at startup.
To investigate, I have attached a debugger to my game and let it launch with Intel GPA's modules loaded at initialisation as it should be (specifically shimloader64.dll that then loads shimd3d64.dll, that finally loads MetricsPipeline64.dll)
It works perfectly well with all other games (even the ones equally Unity and DirectX 11 based) but not for this one.
My debugger revealed that when Intel GPA's modules are loaded, the main thread of my game encounters an access violation when trying to write a memory address.
Taking a look at the call stack I can see that it is executing code within shimd3d64.dll when the error happens (precisely in a call to CreateRemoteThreadEx called from somewhere in shimd3d64.dll)
Since the main thread is the one of my game, it normally shouldn't venture executing code in Intel GPA's modules, therefore I assume that GPA is setting up some sort of hook or detour to redirect the program flow and execute additional actions, most likely during the initialisation of DirectX to enable its features afterwards.
The problem seems to be there in the additional operations that GPA makes my main thread do, but I am not a professional programmer and do not really know how I could solve this issue or further my investigation at this point.
Here is a screen capture of the debugger when encountering the issue:
Do you know of anyone having bumped into this problem in the past?
If someone of this forum's staff or active member read this, have you had other crash on startup problems? And if yes, what did solve the issue please.
I looked for more technical documentation on GPA or a troubleshoot guide but didn't find any, is there one and if so would it be useful?
Any suggestions that might help to solve the issue is more than welcome.
Thank you for your help
I'm sorry that GPA is currently not working with your application. To help figure this out, could you send me the about info section found in the top right of frame analyzer or graphics monitor, it looks like this:
Would you also be able to send me a private message with the workload? I'd like to reproduce the issue on my side to figure out what kind of bug it is and if it's related to your OS version/build, driver, etc.
When I noticed that it didn't work, I decided to update Intel GPA to the latest version, hoping that this would solve my problem, but it did not (my debugger indicate that this is the same problem with both versions, same exception is thrown in the main thread).
Here is the "About" of the up to date version:
Can you give me more details about how to give you "the workload" please?
I don't really understand what you want me to give you.
I intent to install a Windows 7 and try with this operating system, in case the problem is Windows 10 specific.
If you have any idea of other things I could try that may perhaps solve the issue please let me know.
Thank you again for your help.
Just to let you know:
I tried with an older version of Intel GPA (15.4) on Windows 10 x64 fully up to date and it did not work either.
Then I installed a Windows 7 Pro N x64, updated it fully and installed the latest Intel GPA and it finally worked without problems.
No idea why it doesn't on Windows 10 x64 (I tried on different machines with this OS without success).
This is awkward... Turns out that Windows 7 Pro N x64 did not finish to install all updates and after being fully up to date, it doesn't work again, same problem.
I uninstalled the updates manually one by one but then nothing worked anymore, all programs had problems.
So I ended up reinstalling Windows 7 Pro N x64 SP1 then directly disabling Windows Update.
This way it "works", obviously the problem is still there but I can do my tests in peace.
If you want to isolate the problem to identify it precisely I would suggest to install the OS and then install update by update (there's about 200 to install) until it no longer works.
Anyway, it finally works stable, so I'll keep it this way for now.
I'm glad you were able to get GPA to work and be stable. I'll log this with our engineering team and recreate the issue. Out of curiosity what build are you on for Windows 7 that allowed GPA to work and be stable? Just so I can include this with the bug report. I'll keep in touch and might ask additional questions.
Hey Giselle,
My Windows that got GPA working is Windows 7 x64 Pro N SP1, build 6.1.7601.
I turned off the updates (set it to never check for updates + stopped and disabled the service) right after installing, even before installing the network drivers to make sure no updates are installed at all.
Since this comes from a Windows Update, I wouldn't be surprised if it also worked on a fresh Windows 10 install with updates turned off straight from install.
I haven't tested that since I have it working already but chances are it might work with that as well.
I remain available if you have any further questions or if you want me to try things around.
The game I experiment on is a closed beta game therefore I don't think I can share it directly since it is not my own intellectual property, but I am going to ask the developers if that is okay, they might contact you directly then, I will direct them to this forum post.
I have dug a bit more on the issue and isolated what's the exact instruction that makes the initialisation to crash.
At some point during the initialisation (in the additional operations done by the main thread following GPA's hook/detour) there is an assembly instruction call rax that crashes the program since rax has a value that sends the program to a place it has nothing to do, instructions there are not real executable code (please do check my observations, you can simply breakpoint on call rax instructions).
I tried naively to skip the call rax instruction, but then program end up coming back to it and hitting the same breakpoint, so I assume something really necessary is happening there.
However, since I am debugging without shimd3d64.dll's symbols (names, etc...) it is really hard for me to understand precisely what is going on, as I said I am just an amateur developer/reverse engineer but I am convinced that identifying the issue precisely would be easy for someone with your program's source, or at least symbols.
Let me know if I can do anything else to help.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
I'm having an issue with React.js when it comes to adding an array of objects returned by an Axios GET request. The GET request works just fine but the process of trying to add the response to a hook is causing issues.
Right away I feel I should explain part of the title where I say the "Pane seems to crash". I said it this way because when the issue occurs, the pane instantly goes blank and no longer shows up in the browser inspector. But at the same time, no error is generated. I have error checking running in the application but there's no information to go on.
The basic idea is that Axios calls the database and gets a query of ten books. These books are then added to a hook called bookInfo which in turn is referenced by the tableData hook that provides the data for the table.
b1e95dc632