Is there any possibility to add ARM64 support?

[dmex]

XDA ported Process Hacker to ARM some years ago: https://forum.xda-developers.com/showthread.php?t=2179754

The only reason why the official builds don't support ARM is the lack of hardware (or at least someone who can submit patches).

[MagicAndre1981]

@dmex any update on this? I have deployed ARM64 Win10 1909 to my Lumia 950XL and would like to use ProcessHacker

[MagicAndre1981]

@Biswa96 do you want to start working on it and create a PR?

[Biswa96]

Questions:

• Is there any usermode test (only C) I can do to check if the kernel mode driver loaded successfully?
• Does the kernel mode driver depend on any driver other than ksecdd driver? i.e. does it load other driver dynamically (kmode alternative of LoadLibrary)?

[dmex]

Is there any usermode test (only C) I can do to check if the kernel mode driver loaded successfully?

The EnumDeviceDrivers function can check if the module was loaded. See this example: https://docs.microsoft.com/en-us/windows/win32/psapi/enumerating-all-device-drivers-in-the-system

There is another entirely different method by checking page allocations by the driver vs checking loaded drivers (which can be very detailed) but probably isn't needed?

Does the kernel mode driver depend on any driver other than ksecdd driver?

No

[MagicAndre1981]

@Biswa96 do you have test builds? I can test it on WIn10 1909 ARM64 on my Lumia 950XL

[MagicAndre1981]

This test driver works on my 950XL:

sc query kph shows running:

C:\Windows\system32>sc query kph

SERVICE_NAME: kph
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

C:\Windows\system32>

[Biswa96]

Will the X86 version of ProcessHacker work with ARM64 version of the driver? I am think about it like this -- Download the X86 version of processhacker ZIP file, extract it, remove the driver (sys file) in that folder, register the ARM64 driver as kprocesshacker3 service, run the X86 ProcessHacker GUI as admin.

The ARM64 WinPE that I'm using in Raspberry Pi4 doesn't have the X86 emulation layer.

[MagicAndre1981]

x86 processhacker doesn't start at all.

[Biswa96]

The phlib-test project can not be compiled. Errors -- The referenced project '....\phlib\phlib.vcxproj' does not exist. Cannot open include file: 'ph.h'.

[dmex]

@Biswa96

phlib-test should be fixed 👍

[Biswa96]

The X64 platform is missing. Could you add the X64 platform in phlib-test project? When I tried to copy the config from Win32 platform msbuild searches the phlib.lib file in Debug32 folder instead of Debug64.

[dmex]

@Biswa96

I've added the x64 solutions. You'll have to ignore some asserts from UTF16 string length checks - they were incorrectly using UTF8 null terminators instead of UTF16 terminators and have the wrong lengths by 1 character.

[Biswa96]

Now this error is shown with X64 debug, using VS 2019:

LINK : fatal error LNK1181: cannot open input file 'F:\processhacker\phlib\bin\Debug32\phlib.lib'

[dmex]

@Biswa96

The linker tries to open both libraries and you'll need to build the 32bit processhacker.sln to fix the issue. I have no idea why but it does need both libraries present.

[MagicAndre1981]

yes, both exe work fine. Great to have PH running as 64 Bit app 😍

[ge0rdi]

@dmex Is there any plan to add ARM64 support to build scripts? So that it is possible to easily create whole package for ARM64.

I can have a look at it. If you are willing to do that direction.

I can also do some testing on ARM64 devices (I have Surface Pro X at hand).

[Biswa96]

I have been using these commands to build everything in ProcessHacker:

call "%ProgramFiles(x86)%\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64_arm64
msbuild KProcessHacker\KProcessHacker.sln -property:Configuration=Debug -property:Platform=ARM64 -verbosity:minimal
msbuild ProcessHacker.sln -property:Configuration=Debug -property:Platform=ARM64 -verbosity:minimal
mkdir sdk\lib\arm64
copy bin\DebugARM64\ProcessHacker.lib sdk\lib\arm64
msbuild plugins\Plugins.sln -property:Configuration=Debug -property:Platform=ARM64 -verbosity:minimal

Some catches:

• The 3rd and 4th commands are handled by tools/CustomBuildTool but it doesn't support ARM64 platform.
• The "ExtendedTools" plugin crashed with 0xC06D007F error in my WinPE ARM64 in qemu.
• The KprocessHacker driver need to be signed to work properly.

[ge0rdi]

@Biswa96 Thank you. I know how to build ProcessHacker. I just wanted to offer working on kind of official build support (in CustomBuildTools and scripts).

The "ExtendedTools" plugin crashed with 0xC06D007F error in my WinPE ARM64 in qemu.

It seems to be working fine on Surface X device. I can see GPU/disk/network graphs.

The KprocessHacker driver need to be signed to work properly.

Yup. For now I have testsigning enabled on device. Driver seems to be working just fine.

[MagicAndre1981]

Yup. For now I have testsigning enabled on device. Driver seems to be working just fine.

yes, driver also works for Lumia 950XL. I could also try the plugins. Is the ARM64 configuration already added for plugins?

[ge0rdi]

@MagicAndre1981 Yes. Just open Plugins.sln in VS, pick ARM64 platform and rebuild whole solution.

Plugins seems to work without any issue for me.

[MagicAndre1981]

doesn't work for me. I always get this message :

LINK : fatal error LNK1104: cannot open file 'ProcessHacker.lib'

Win32 and x64 compile fine. I first opened ph sln and build it for all configurations.

[MagicAndre1981]

ok, this is easy, in Build.cs add 2 lines:

https://github.com/processhacker/processhacker/blob/master/tools/CustomBuildTool/Build.cs#L82 add here arm64

and here copy the lib

https://github.com/processhacker/processhacker/blob/master/tools/CustomBuildTool/Build.cs#L492

[ge0rdi]

@Biswa96 @MagicAndre1981 See PR #635.

[Biswa96]

The patch works and looks good to me. Though the patch focuses on the sdk option, I thought it would be better if arm64 platform is added as a whole in CustomBuildTool which also creates zip files and artifacts in appveyor. Maybe it is in dmex's area.

[ge0rdi]

I thought it would be better if arm64 platform is added as a whole in CustomBuildTool which also creates zip files and artifacts in appveyor

This is what I was trying to ask @dmex here. Whether he wants to go that direction or what are his plans regarding ARM64. I'd like to work on that if it is desired.

[MagicAndre1981]

@Biswa96

here is now a way to get Windows 10 ARM64 running on Pi4 via USB 3.0 boot:

https://rpi4-uefi.dev/alternate-guide-running-windows-10-on-the-pi-4/

[joaomoreno]

Looking forward to this.

[Biswa96]

ARM64 platform is added to plugins-extra repository also.

[dmex]

I have been using these commands to build everything in ProcessHacker

I've added the build script: https://github.com/processhacker/processhacker/commit/280fd94feb0486b4ccd11bce8ab0267468a02292 👍

[MagicAndre1981]

@dmex can you add ARM64 to nightly build?

[Biswa96]

I thought something will be added to CustomBuildTools so that the result will be seamless with other builds. Also the script doesn't handle release mode.

[paulstelian97]

Adding comment to be notified of the progress. I've got an Allview Allbook Q notebook with Snapdragon 835 so having an ARM64 port of Process Hacker (which actually works correctly -- the x86 port reports higher CPU usage than Task Manager does) would definitely be nice.

[MagicAndre1981]

I've added the build script: 280fd94 👍

I get this error during build:

E:\processhacker\plugins\ToolStatus\taskbar.c(401,31): error C2220: the following warning is treated as an error [E:\processhacker\plugins\ToolStatus\ToolStatus.vcxproj]
E:\processhacker\plugins\ToolStatus\taskbar.c(401,31): warning C4013: '_malloca' undefined; assuming extern returning int [E:\processhacker\plugins\ToolStatus\ToolStatus.vcxproj]
E:\processhacker\plugins\ToolStatus\taskbar.c(401,61): warning C4047: '=': 'PFLOAT' differs in levels of indirection from 'int' [E:\processhacker\plugins\ToolStatus\ToolStatus.vcxproj]
E:\processhacker\plugins\ToolStatus\taskbar.c(422,11): warning C4013: '_freea' undefined; assuming extern returning int [E:\processhacker\plugins\ToolStatus\ToolStatus.vcxproj]
E:\processhacker\plugins\ToolStatus\taskbar.c(460,61): warning C4047: '=': 'PFLOAT' differs in levels of indirection from 'int' [E:\processhacker\plugins\ToolStatus\ToolStatus.vcxproj]

VS2019 16.8.3 /19041 SDK/WDK

[dmex]

@MagicAndre1981

Add #include <malloc.h> into the \ToolStatus\taskbar.c header.

I fixed this last week but haven't pushed it live yet.

[MagicAndre1981]

I fixed this last week but haven't pushed it live yet.

works, I also found the docs right now

In Sysinfo->GPU I get a assert when I click on details:

[MagicAndre1981]

Btw, the Windows on ARM project now supports the Lumia Dock , so you can add a monitor and extend the desktop. So if anyone has the old things, you can use to play with ARM64 version of Windows 10 with the dock + USB devices + Monitor and no longer need to use the small phone screen

[dmex]

@MagicAndre1981

In Sysinfo->GPU I get a assert when I click on details:

I'll need the stacktrace to know what caused that issue. There are more than 100,000 calls to that function which could have triggered that assert.

[MagicAndre1981]

I'll need the stacktrace to know what caused that issue. There are more than 100,000 calls to that function which could have triggered that assert.

WinDbg Preview doesn't allow starting ARM64, so I used old ARM64 Windbg, started PH and this happens in ExtendedTools!EtpQueryDeviceProperty gpumon.c @ 207

00 000000b1`b71fe410 00007ff7`8fc0a680 ProcessHacker!__crt_interlocked_read<long>+0x530 [minkernel\crts\ucrt\src\appcrt\startup\assert.cpp @ 388] 
01 000000b1`b71fe8e0 00007ff7`8fc0e7e8 ProcessHacker!__crt_interlocked_read<long>+0x1f8 [minkernel\crts\ucrt\src\appcrt\startup\assert.cpp @ 423] 
02 000000b1`b71fe920 00007ff7`8fabce60 ProcessHacker!wassert+0x28 [minkernel\crts\ucrt\src\appcrt\startup\assert.cpp @ 443] 
03 000000b1`b71fe950 00007ffd`4cbb1ec8 ProcessHacker!PhAllocate+0x30 [E:\processhacker\phlib\basesup.c @ 463] 
04 000000b1`b71fe970 00007ffd`4cbb1294 ExtendedTools!EtpQueryDeviceProperty+0xd8 [E:\processhacker\plugins\ExtendedTools\gpumon.c @ 207] 
05 000000b1`b71fea50 00007ffd`4cbacc70 ExtendedTools!EtQueryDeviceProperties+0x164 [E:\processhacker\plugins\ExtendedTools\gpumon.c @ 429] 
06 000000b1`b71fec90 00007ffd`4cbadeb8 ExtendedTools!EtpQueryAdapterDeviceProperties+0x70 [E:\processhacker\plugins\ExtendedTools\gpudetails.c @ 73] 
07 000000b1`b71fed70 00007ffd`4cbae2b0 ExtendedTools!EtpGpuDetailsEnumAdapters+0x188 [E:\processhacker\plugins\ExtendedTools\gpudetails.c @ 376] 
08 000000b1`b71fee10 00007ffd`71da2890 ExtendedTools!EtpGpuDetailsDlgProc+0x320 [E:\processhacker\plugins\ExtendedTools\gpudetails.c @ 455] 
09 000000b1`b71fef10 00007ffd`71da23c0 USER32!UserCallDlgProcCheckWow+0x1c0
0a 000000b1`b71ff000 00007ffd`71da1238 USER32!DefDlgProcWorker+0xb0
0b 000000b1`b71ff0a0 00007ffd`71daa650 USER32!DefDlgProcW+0x38
0c 000000b1`b71ff0d0 00007ffd`71da9cec USER32!UserCallWinProcCheckWow+0x350
0d 000000b1`b71ff2b0 00007ffd`71da1e80 USER32!SendMessageWorker+0x6f4
0e 000000b1`b71ff340 00007ffd`71da13e8 USER32!InternalCreateDialog+0x9d0
0f 000000b1`b71ff520 00007ffd`71da1320 USER32!CreateDialogIndirectParamAorW+0x58
10 000000b1`b71ff560 00007ffd`4cbae6b8 USER32!CreateDialogParamW+0xd0
11 000000b1`b71ff5c0 00007ff7`8fac4e40 ExtendedTools!EtGpuDetailsDialogThreadStart+0xe8 [E:\processhacker\plugins\ExtendedTools\gpudetails.c @ 570] 
12 000000b1`b71ff8a0 00007ffd`717ecc64 ProcessHacker!PhpBaseThreadStart+0xe8 [E:\processhacker\phlib\basesup.c @ 206] 
13 000000b1`b71ff930 00007ffd`72b70c44 KERNEL32!BaseThreadInitThunk+0x34
14 000000b1`b71ff970 00000000`00000000 ntdll!RtlUserThreadStart+0x44

[dmex]

I'm closing this issue since the project is supported and compiles with ARM64... If there are issues/assertions running ARM64 builds then please create a new issue 👍

---

@MagicAndre1981 That issue will be fixed in the latest nightly.

[MagicAndre1981]

@MagicAndre1981 That issue will be fixed in the latest nightly.

ok, but please release the ARM64 as nightly. I want to remove the C++ workload to save space in my VM

[dmex]

release the ARM64 as nightly

I don't have any ARM hardware and if something breaks it won't get fixed for days/weeks.

[MagicAndre1981]

I don't have any ARM hardware and if something breaks it won't get fixed for days/weeks.

I'm using my old Lumia 950XL and run Win10 ARM64, you can try a Raspberry Pi 4 if you have one.

[paulstelian97]

If you want, I can (not very regularly, to be fair) test ARM64 releases myself (not enough time after my normal job to actually contribute though). Allview Allbook Q (SD835).

[MagicAndre1981]

ok, now it gets complicated @dmex .

You can now run x64 software on Windows 11 ARM64, so your ARM64 hacks fail.

I see now Virtual CPU@2.00GHz on my Raspi4 when running the x64 version because it is not the ARM64 build so it executes the cpuid command

So maybe it is better to check the cpu architecture at runtime

[dmex]

when running the x64 version because it is not the ARM64 build maybe it is better to check the cpu architecture at runtime

You could also use the ARM build when running on ARM where the emulation won't be a problem?

[MagicAndre1981]

You could also use the ARM build when running on ARM where the emulation won't be a problem?

as I said, I no longer install the C++ workload to save space in my VMs so I can't recompile it. And I only do what endusers do, download and run your last nightly

[Biswa96]

The build procedure changed a lot. I think the CustomBuildTool need to add something for ARM64. The phapppub.h and other sdk headers are not copied automatically to build plugins.

[dmex]

@Biswa96

Use the \build\build_arm64.cmd script... That script will compile the project and plugins with ARM versions. CustomBuildTool itself has never supported ARM.

There are also hundreds of places throughout the entire project which assume either System32 or Syswow64 which are not correct for ARM processes and require support for RtlReplaceSystemDirectoryInPath so even after building the project a lot of information won't be correct.

[DavidXanatos]

I just got a PI4 and need a good task manager for it :D so I may need to look into porting as much as I can. For example i don't see yet a good way to distinguish x64 from ARM64EC processes when querying SystemSupportedProcessorArchitectures2 they look exactly the same, mut M$'s task manager can tel them apart, I wonder how... may be reading PEB fields like ChpeV2ProcessInfo in wonder...