DR crashes when running C# on Win 10 #3046
Comments
|
I'm not too knowledgeable about C# but I thought that by default, the C# compiler will emit bytecode for CLR as opposed to native code. I doubt that DynamoRIO is expected to work on this non-native code... |
|
You are right regarding the C# compiler, but as the JIT is included in the binary along with the CIL (~Bytecode), from an external view there is no observable difference. Interestingly the code works on Windows7 using the latest DR, so I guess the actual issue is the Windows API? |
|
"Windows 10" is not precise enough (from DR's point of view it's like saying "Windows prior to 10" as each Windows 10 update is a major update, adding system calls and changing system call numbers). Which release of 10 is this? DynamoRIO-Windows-7.0.0-RC1 has no support for Win10 TH2 (1511) or higher. The core\win32\ntdll.c:662 assert listed above is known and is a duplicate of the general TH2 issue #1825. It was fixed a while back. Please use a more recent version of DR (one of the "cronbuilds"). With the more recent version 7.0.17689, it looks like the app executed fine (though it seems to hook a lot of syscall wrappers -- or maybe that's some AV software on your system? Best to rule that out as the exit crash could come from that too) until it exited. A callstack of the exit crash (from windbg) would help to figure out what's going on. |
|
Hi, thanks for your quick response. The exact windows release is: Regarding the AV: That is possible as other (fine-running) apps show similar conflicts. When running on a similar system without AV, there are no hooking conflics, but the app crashes as well. After I have installed windbg (apparently not included in the Win10 SDK Debugging Tools), I will report back. |
|
The issue also occurs for a windows 7 build. The application is a dummy C# application (x64), using CLR dotnet.
Here is a crash log: windbg output at crash: |
|
See a similar issue and discussion on the users list: https://groups.google.com/forum/#!topic/DynamoRIO-Users/RXXRxYa08QQ Resuming that here with more details: These .NET apps have an entry point offset of 0, just pointing at the base of the binary. What is happening is that there is special support in the win10 (maybe win7+?) loader to change the application's start address in the initial CONTEXT (Rcx there) from the executable entry point, set by the kernel, to MSCOREE!CorExeMain_Exported. In old (pre-win7 maybe) Windows versions, instead mscoree itself would patch the entry point, and not change the initial CONTEXT at all. The drrun injector is rather late, and it uses the CONTEXT seen from the parent and caches it. It thus ignores this change by the loader and tries to run the start address set by the kernel, resulting in the observed crashes. If you use from-parent injection with location "4", the app should run correctly as DR injects before the special code that changes the start point. This requires DR being in a parent process just because we never implemented early injection support in drrun (#607): However, injecting that early does not have good client support if the client wants to use Windows libraries, since loading a private kernelbase that early just doesn't work. We have a half-implemented "drwinapi" trying to solve that but it was never finished enough for most clients. The simplest, targeted short-term fix would be to change the late injection code to update the cached context with the new Rcx/Eax value. Long-term of course it would be great to move default injection earlier via a filled-in drwinapi. It would also be nice to add a .NET test to the regression suite to catch regressions like this. |
On recent Windows versions, the loader changes the start address of the initial thread's CONTEXT. However, for late injection, DR had already cached the address to the value set by the kernel, which crashes. We solve that by updating the start address register when we run our takeover code. Adds a .NET test to the suite. Fixes #3046
On recent Windows versions, the loader changes the start address of the initial thread's CONTEXT. However, for late injection, DR had already cached the address to the value set by the kernel, which crashes. We solve that by updating the start address register when we run our takeover code. Adds a .NET test to the suite. Fixes #3046
On recent Windows versions, the loader changes the start address of the initial thread's CONTEXT. However, for late injection, DR had already cached the address to the value set by the kernel, which crashes. We solve that by updating the start address register when we run our takeover code. Adds a .NET test to the suite. Fixes #3046
On recent Windows versions, the loader changes the start address of the initial thread's CONTEXT. However, for late injection, DR had already cached the address to the value set by the kernel, which crashes. We solve that by updating the start address register when we run our takeover code. Adds a .NET test to the suite. Fixes #3046
|
Hey @derekbruening i was reading this and what does early_inject_location mean ? |
If you search the code you'll see the option in optionsx.h referencing the enum of values like |
Dynamorio crashes when running a simple C# Application on Windows 10:
OS:
Windows 10DR:
drrun version 7.0.0 -- build 1(both 32 and 64 bit)Compiler:
MSBuild\15.0\Bin\Roslyn\csc.exeC# Code:
Execution:
Edit: When using,
drrun version 7.0.17689 -- build 0the output is more precise:The text was updated successfully, but these errors were encountered: