System call information is missing for this operating system

[MarekKnapek]

Steps to reproduce:

drmemory.exe -- cmd /c echo abcdef

Expected result:

No error message.

Actual result:

---------------------------
Dr. Memory Notice: C:\Windows\system32\cmd.exe(9972)
---------------------------
System call information is missing for this operating system: WinVer=105;Rel=2009;Build=20348;Edition=ServerStandard. Restarting to trigger auto-generation of system call information. Re-run with -ignore_kernel to attempt to continue instead.


---------------------------
OK   
---------------------------

Steps to reproduce:

drmemory.exe -ignore_kernel -- cmd /c echo abcdef

Expected result:

No error message.

Actual result:

---------------------------
Dr. Memory Notice: C:\Windows\system32\cmd.exe(25512)
---------------------------
System call information is missing for this operating system: WinVer=105;Rel=2009;Build=20348;Edition=ServerStandard.


---------------------------
OK   
---------------------------

Windows Server 2022 for x64, version 10.0.20348.1970.
DrMemory for Windows x64, version 2.6.0 -- build 0.

I'm a C++ programmer, so I believe I can provide such missing kernel information if you tell me how to extract them from my system. I could provide you with a pull request if you want.

[bernhardcl]

I get the same although with a different Windows version:

System call information is missing for this operating system: WinVer=105;Rel=2009;Build=19045;Edition=Professional.

For me maybe an issue since I am using it via msys2 as well!?

[theOriginalFelto]

I have the same issue with this OS: WinVer=105; Rel=2009; Build=22621; Edition=ServerDatacenter.

I saw a lot of issues where the solution was to put this file to the bin folder of DrMemory, but this link does not work for me. Are there any updates for this wow file? Hope that someone can reach out :)

Might I add, I have the local/portable installation (the one from the .zip file) and would prefer to not have to use the installation file.

[derekbruening]

Do things work fine on the restart? This should be a one-time message (I think -quiet should suppress).

[theOriginalFelto]

Did you mean on restart of command or the system? When running the command repeatedly, the error still persists even after system reboot.

While -quiet does suppress the message, the final results still seem kind of incomplete sometimes. For this simple command that @MarekKnapek mentioned, the final result is presented. But, in my usecase where I run a binary tool for GPU monitoring which uses multiple syscalls in one run, I don't have the final result.

[derekbruening]

The drmemory command should restart itself after dismissing this popup message. You mean that auto-relaunch pops up the same message again?

[theOriginalFelto]

In the same PowerShell terminal multiple invocations of the command produce the same error, yes.

[MarekKnapek]

Not sure it is related to this exact issue, but I guess DrMemory is no longer maintained and it does not work good enough on Windows10. I did little investigation and I found out some stuff.

• I cloned DrMemory source code.
• It uses CMake based build system, I generated Visual Studio 2022 solution.
• I built the product.
• I created little console based application with a memory issue.
• I tried to run DrMemory on that buggy application, stepping thru DrMemory in debugger.
• DrMemory creates new process (the buggy app) in suspended mode.
• I attached Visual Studio debugger to that process also.
• Then it "loads" dynamorio.dll helper DLL into itself and subsequently it "loads" it into the target process. It does not really "load" the DLL, rather it maps it, creates new section and fixes relocations manually, bypassing the ntdll loader.
• It then changes PC / EIP / RIP register / CONTEXT structure of the target thread / process to point to the just loaded DLL.
• It resumes the suspended target process.
• The dynamorio.dll in the target process takes control. And I guess it tries to emulate what ntdll loader would do at process startup. And I guess it does not do good job at it, as Windows 10 might behave slightly differently compared to older Windows, and there was not enough effort to maintain the product. In my case dynamorio.dll "loads" combase.dll and combase.dll fails inside its DllMain function for whatever reason. I suspect that the reason is that DrMemory is no longer maintained and Windows 10 (ntdll loader) behaves slightly differently than older Windows versions.

[derekbruening]

Not sure it is related to this exact issue

No, it is not related. DynamoRIO's private loader and the reason for its existence is documented at
https://dynamorio.org/using.html#sec_extlibs. Private loading of the libraries used by the tool itself is a separate issue from the tool needing to know about system call inputs and outputs in order to track allocations and initializations properly.