microsoft
minject --force --inplace crashes reproducibly, on a specific machine with a specific executable
Silimar to #850, but in my case minject only crashes for one of seven executables, and only on one machine. However, this happens for both version 2.1.2 and 3.0.1 of minject.exe.
The machine where the crash occurs is running VS 2022 on Windows 10, minject fails if called from the command line as well as if called by the build service (Atlassian Bamboo), using the absolute path to the executable.
But: If I cd to the executable directory and give only the local filename, minject succeeds.
It is probably not related to the full path name's length, as longer paths succeed.
I attached two screenshots of Visual Studio Debugger used on the dumpfile
I can provide the dumpfile and the path names as well as the verbose output of minject on request.
I strongly recommend you enable the "Microsoft Symbol Server" in VS.
Seeing the ntdll & ucrtbase symbol names would at least provide a rough idea where things go wrong.
Also, just at the end of the module lists I can see umppc and csxumd64 DLLs, which apparently belongs to CrowdStrike, It may be worthwhile to test with disabled - If it injects itself into processes, it may as well interfere with minject.exe.
OK, forgot to enable the Microsoft Symbol Servers. Here the call stack including the symbols:
The file name in question should be "D:/bamboo/xml-data/build-dir/IS-CTP0-W1/source_build/TP_RelWithDebInfo/ov/radiometrix/radiometrix.exe" or "D:/bamboo/xml-data/build-dir/IS-CTP0-W1/source_build/TP_RelWithDebInfo/ov/radiometrix/radiometrix-mi.exe" Note: Yes, these are forward slashes, not backslashes.
But, as it is a heap corruption, the error may have occurred earlier...
But, as it is a heap corruption, the error may have occurred earlier...
Indeed. If this was Linux, I'd say "see what valgrind says", or more generally, run it through some tool that detects memory allocation problems.
Unfortunately, I don't know an equivalent for Windows off-hand. I think there are tools, and I vaguely even recall that there's some "global flag" built into Windows to help here, but I don't really have a lot of experience with either. But if you can spare the time, might be worth looking into it - I'm assuming more info that can be dug up means it's more likely that Daan can help you. (AFAIK he's the only one that can ultimately change minject.)
Well...
If I run minject.exe within the Debugger (Visual Studio 2022), it runs without any issue. If I run exactly the same executable with exactly the same arguments from the command line, it crashes:
I might have fixed this issue in the latest dev branch -- if you run minject -h it should give version 1.2. Can you try if that works for you?
(and if not, maybe you can send the exe that causes the crash so I can investigate further)
Well, the minject on dev gives me "1.3" when called with minject -h
Nevertheless, is still crashes, but with a different call stack:
However, this time it also crashes when called from the Debug Console.
There is some news regarding ticket #850 including some stack trace information.
