Skip to content

feat: Add RAM Usage entry using psapi.h windows API#71

Merged
supervoidcoder merged 5 commits intomainfrom
add-memory-usage
Feb 6, 2026
Merged

feat: Add RAM Usage entry using psapi.h windows API#71
supervoidcoder merged 5 commits intomainfrom
add-memory-usage

Conversation

@supervoidcoder
Copy link
Owner

@supervoidcoder supervoidcoder commented Feb 6, 2026

Summary by CodeRabbit

  • New Features
    • Adds real-time RAM usage reporting to the PID inspection output, displayed alongside command and working directory information.
    • RAM is shown in human-readable units and appears in both ANSI and non-ANSI terminal modes when available.
    • Minor formatting adjustments were made to accommodate the new RAM display without changing existing control flow.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 6, 2026

Walkthrough

Adds RAM usage reporting to main.cpp by including psapi.h and calling GetProcessMemoryInfo to read WorkingSetSize, format it into bytes/KB/MB/GB/TB, and print "RAM Usage" in both ANSI and non-ANSI output paths after the Working Directory display (gated on success).

Changes

Cohort / File(s) Summary
Memory Usage Reporting
main.cpp
Includes psapi.h and calls GetProcessMemoryInfo to obtain pmc.WorkingSetSize; formats as human-readable units and prints "RAM Usage" in ANSI and non-ANSI terminal flows. Inserted after Working Directory output in two PID-inspection locations; output shown only on successful call.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 I nudge the code with nimble nose,
I peek where working-set size grows,
A little number, neat and bright,
RAM whispers softly in the light,
Hopping on — the output shows. 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding a RAM Usage feature using Windows API (psapi.h), which is clearly supported by the file summary showing memory usage reporting implementation.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch add-memory-usage

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
main.cpp (1)

814-829: ⚠️ Potential issue | 🟠 Major

RAM usage is displayed as raw bytes — should be human-readable.

WorkingSetSize is in bytes, so a process using 50 MB will print RAM Usage: 52428800. Users will have no idea what that number means without a unit. Convert to a friendlier format (e.g., MB with one decimal).

Also, zero-initialize pmc for safety.

Proposed fix
-	PROCESS_MEMORY_COUNTERS pmc;
-	if ( GetProcessMemoryInfo( hProcess, &pmc, sizeof(pmc)) ) {
-		if (IsVirtualTerminalModeEnabled()) {
-                 std::cout << "\033[1;32mRAM Usage\033[0m: " << pmc.WorkingSetSize << std::endl;
-            } else {
-                    std::cout << "RAM Usage: " << pmc.WorkingSetSize << std::endl;
-                }
-	}
+	PROCESS_MEMORY_COUNTERS pmc{};
+	if ( GetProcessMemoryInfo( hProcess, &pmc, sizeof(pmc)) ) {
+		double memMB = static_cast<double>(pmc.WorkingSetSize) / (1024.0 * 1024.0);
+		if (IsVirtualTerminalModeEnabled()) {
+			std::cout << "\033[1;32mRAM Usage\033[0m: " << std::fixed << std::setprecision(1) << memMB << " MB" << std::endl;
+		} else {
+			std::cout << "RAM Usage: " << std::fixed << std::setprecision(1) << memMB << " MB" << std::endl;
+		}
+	}

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
main.cpp (2)

822-840: ⚠️ Potential issue | 🔴 Critical

Integer overflow in GB/TB thresholds and divisors.

1000 * 1000 * 1000 * 1000 is evaluated as int arithmetic (all literals are int), producing 10¹² which overflows a 32-bit signed integer. This is undefined behavior and will cause the GB comparison on Line 834 and TB division on Line 838 to produce garbage results. Confirmed by Cppcheck.

Use size_t casts or ULL suffixes to force the arithmetic into a wide enough type:

🐛 Proposed fix
-		if (RAM < 1000) {
-			// if less than 1000 bytes (which is a kilobyte) then just return bytes
-			FRAM = std::to_string(RAM) + " B";
-				}
-		else if (RAM < 1000 * 1000) { 
-			
-			FRAM = std::to_string(RAM / 1000) + " KB";
-		}
-		else if (RAM < 1000 * 1000 * 1000) { 
-			
-			FRAM = std::to_string(RAM /( 1000 * 1000)) + " MB";
-		}
-		else if (RAM < 1000 * 1000 * 1000 * 1000) {
-			FRAM = std::to_string(RAM /( 1000 * 1000 * 1000)) + " GB";
-		}
-		else {
-			FRAM = std::to_string(RAM /( 1000 * 1000 * 1000 * 1000)) + " TB";
-			// if someone actually reaches this i'm concerned
-		}
+		if (RAM < 1000ULL) {
+			FRAM = std::to_string(RAM) + " B";
+		}
+		else if (RAM < 1000ULL * 1000) {
+			FRAM = std::to_string(RAM / 1000ULL) + " KB";
+		}
+		else if (RAM < 1000ULL * 1000 * 1000) {
+			FRAM = std::to_string(RAM / (1000ULL * 1000)) + " MB";
+		}
+		else if (RAM < 1000ULL * 1000 * 1000 * 1000) {
+			FRAM = std::to_string(RAM / (1000ULL * 1000 * 1000)) + " GB";
+		}
+		else {
+			FRAM = std::to_string(RAM / (1000ULL * 1000 * 1000 * 1000)) + " TB";
+		}

845-853: ⚠️ Potential issue | 🟠 Major

Non-ANSI branch prints raw bytes instead of the formatted string.

Line 846 (ANSI path) correctly prints FRAM, but Line 852 (non-ANSI path) prints pmc.WorkingSetSize — the raw byte count. This means users without ANSI terminal support see something like RAM Usage: 12345678 instead of RAM Usage: 12 MB.

🐛 Proposed fix
             } else {
-                    std::cout << "RAM Usage: " << pmc.WorkingSetSize << std::endl;
+                    std::cout << "RAM Usage: " << FRAM << std::endl;
                 }
🧹 Nitpick comments (1)
main.cpp (1)

814-815: Consider zero-initializing PROCESS_MEMORY_COUNTERS.

Uninitialized struct members could contain garbage if GetProcessMemoryInfo ever partially fills the struct. Minor defensive measure.

Proposed fix
-	PROCESS_MEMORY_COUNTERS pmc;
+	PROCESS_MEMORY_COUNTERS pmc{};

@supervoidcoder
Copy link
Owner Author

@coderabbitai YAY IT WORKS! what cool interesting stuff can we see from this now?

D:\a\win-witr\win-witr>win-witr --pid 4
Target: System
Error: Unable to query executable path. Error code: 31
Maybe Access is Denied or the process is running entirely in RAM.
Process: System (pid 4)
Hint: This error indicates a driver error, but in win-witr, it often means you are calling a pseudo-process, such as System, Registry, or other processes that only exist in RAM as a kernel process. It is often easy to tell them apart if they lack a .exe extension.
User: N/A (Failed to access info)
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 172 KB

Why It Exists:
Secure System (PID 92)
└─ Registry (PID 132)
└─ smss.exe (PID 516)

Started: 9 minutes ago (Fri 2026-02-06 16:38:01 +0000)
Running test: D:\a\win-witr\win-witr\tests\process\process.bat

D:\a\win-witr\win-witr>win-witr winlogon.exe
Target: winlogon.exe
Process: winlogon.exe (pid 6800)
Executable Path: C:\Windows\System32\winlogon.exe
User: SYSTEM
Command: winlogon.exe {F4817891-DD93-48C3-9D70-E38CC11A0000}
Working Directory: C:\Windows\system32
RAM Usage: 13 MB

Why It Exists:
winlogon.exe (PID 6800)
└─ fontdrvhost.exe (PID 6848)
└─ dwm.exe (PID 6872)

Started: 9 minutes ago (Fri 2026-02-06 16:38:31 +0000)

D:\a\win-witr\win-witr>win-witr lsass.exe
Target: lsass.exe
Process: lsass.exe (pid 988)
Executable Path: C:\Windows\System32\lsass.exe
User: SYSTEM
Command: C:\Windows\system32\lsass.exe
Working Directory: C:\Windows\system32
RAM Usage: 32 MB

Why It Exists:
wininit.exe (PID 836)
└─ lsass.exe (PID 988)

Started: 9 minutes ago (Fri 2026-02-06 16:38:05 +0000)

D:\a\win-witr\win-witr>win-witr win-witr.exe
Target: win-witr.exe
Process: win-witr.exe (pid 11388)
Executable Path: D:\a\win-witr\win-witr\win-witr.exe
User: runneradmin
Command: win-witr win-witr.exe
Working Directory: D:\a\win-witr\win-witr
RAM Usage: 4 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ Runner.Listener.exe (PID 8196)
└─ Runner.Worker.exe (PID 8892)
└─ pwsh.exe (PID 2796)
└─ cmd.exe (PID 3900)
└─ win-witr.exe (PID 11388)

Started: 0 seconds ago (Fri 2026-02-06 16:47:36 +0000)

D:\a\win-witr\win-witr>win-witr wininit.exe
Target: wininit.exe
Process: wininit.exe (pid 836)
Executable Path: C:\Windows\System32\wininit.exe
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 9 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ LsaIso.exe (PID 980)
└─ lsass.exe (PID 988)
└─ fontdrvhost.exe (PID 8)

Started: 9 minutes ago (Fri 2026-02-06 16:38:05 +0000)

D:\a\win-witr\win-witr>win-witr explorer.exe
Target: explorer.exe
Process: explorer.exe (pid 7072)
Executable Path: C:\Windows\explorer.exe
User: runneradmin
Command: C:\Windows\Explorer.EXE
Working Directory: C:\Windows\system32
RAM Usage: 163 MB

Why It Exists:
explorer.exe (PID 7072)
└─ AzureArcSysTray.exe (PID 8908)
└─ ServiceFabricLocalClusterManager.exe (PID 9048)

Started: 9 minutes ago (Fri 2026-02-06 16:38:35 +0000)

D:\a\win-witr\win-witr>win-witr Registry
Target: Registry
Error: Unable to query executable path. Error code: 31
Maybe Access is Denied or the process is running entirely in RAM.
Process: Registry (pid 132)
Hint: This error indicates a driver error, but in win-witr, it often means you are calling a pseudo-process, such as System, Registry, or other processes that only exist in RAM as a kernel process. It is often easy to tell them apart if they lack a .exe extension.
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 68 MB

Why It Exists:
Registry (PID 132)

Started: 9 minutes ago (Fri 2026-02-06 16:38:00 +0000)

D:\a\win-witr\win-witr>win-witr csrss.exe
Target: csrss.exe
Process: csrss.exe (pid 740)
Executable Path: C:\Windows\System32\csrss.exe
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 6 MB

Why It Exists:
csrss.exe (PID 740)

Started: 9 minutes ago (Fri 2026-02-06 16:38:04 +0000)

D:\a\win-witr\win-witr>win-witr fontdrvhost.exe
Target: fontdrvhost.exe
Process: fontdrvhost.exe (pid 8)
Executable Path: C:\Windows\System32\fontdrvhost.exe
User: UMFD-0
Command: "fontdrvhost.exe"
Working Directory: C:\Windows\system32
RAM Usage: 4 MB

Why It Exists:
wininit.exe (PID 836)
└─ fontdrvhost.exe (PID 8)

Started: 9 minutes ago (Fri 2026-02-06 16:38:07 +0000)

D:\a\win-witr\win-witr>win-witr svchost.exe
Target: svchost.exe
Process: svchost.exe (pid 480)
Executable Path: C:\Windows\System32\svchost.exe
User: SYSTEM
Command: C:\Windows\system32\svchost.exe -k DcomLaunch -p
Working Directory: C:\Windows\system32
RAM Usage: 34 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 480)
└─ WmiPrvSE.exe (PID 4396)
└─ backgroundTaskHost.exe (PID 7536)
└─ StartMenuExperienceHost.exe (PID 8012)
└─ SearchHost.exe (PID 8136)
└─ RuntimeBroker.exe (PID 5036)
└─ UserOOBEBroker.exe (PID 8300)
└─ OpenConsole.exe (PID 3076)
└─ WindowsTerminal.exe (PID 3424)
└─ RuntimeBroker.exe (PID 8836)
└─ RuntimeBroker.exe (PID 11672)
└─ WmiPrvSE.exe (PID 13040)
└─ TiWorker.exe (PID 15220)

Started: 9 minutes ago (Fri 2026-02-06 16:38:07 +0000)

D:\a\win-witr\win-witr>win-witr smss.exe
Target: smss.exe
Process: smss.exe (pid 516)
Executable Path: C:\Windows\System32\smss.exe
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 1 MB

Why It Exists:
smss.exe (PID 516)

Started: 9 minutes ago (Fri 2026-02-06 16:38:01 +0000)

D:\a\win-witr\win-witr>win-witr services.exe
Target: services.exe
Process: services.exe (pid 960)
Executable Path: C:\Windows\System32\services.exe
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 11 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 480)
└─ svchost.exe (PID 1080)
└─ svchost.exe (PID 1132)
└─ svchost.exe (PID 1284)
└─ svchost.exe (PID 1328)
└─ svchost.exe (PID 1460)
└─ svchost.exe (PID 1504)
└─ svchost.exe (PID 1564)
└─ svchost.exe (PID 1608)
└─ svchost.exe (PID 1604)
└─ svchost.exe (PID 1620)
└─ svchost.exe (PID 1628)
└─ svchost.exe (PID 1664)
└─ svchost.exe (PID 1868)
└─ vmms.exe (PID 1948)
└─ svchost.exe (PID 2032)
└─ svchost.exe (PID 1096)
└─ svchost.exe (PID 2136)
└─ svchost.exe (PID 2240)
└─ svchost.exe (PID 2300)
└─ svchost.exe (PID 2292)
└─ svchost.exe (PID 2316)
└─ svchost.exe (PID 2372)
└─ svchost.exe (PID 2440)
└─ svchost.exe (PID 2452)
└─ svchost.exe (PID 2484)
└─ svchost.exe (PID 2492)
└─ svchost.exe (PID 2536)
└─ svchost.exe (PID 2560)
└─ svchost.exe (PID 2700)
└─ svchost.exe (PID 2716)
└─ svchost.exe (PID 2732)
└─ svchost.exe (PID 2860)
└─ svchost.exe (PID 2900)
└─ svchost.exe (PID 2984)
└─ svchost.exe (PID 2852)
└─ svchost.exe (PID 2600)
└─ svchost.exe (PID 3080)
└─ svchost.exe (PID 3148)
└─ svchost.exe (PID 3192)
└─ spoolsv.exe (PID 3280)
└─ svchost.exe (PID 3348)
└─ svchost.exe (PID 3476)
└─ svchost.exe (PID 3484)
└─ svchost.exe (PID 3492)
└─ svchost.exe (PID 3504)
└─ svchost.exe (PID 3544)
└─ svchost.exe (PID 3556)
└─ MpDefenderCoreService.exe (PID 3676)
└─ dockerd.exe (PID 3700)
└─ SMSvcHost.exe (PID 3708)
└─ svchost.exe (PID 3716)
└─ svchost.exe (PID 3748)
└─ svchost.exe (PID 3756)
└─ WaAppAgent.exe (PID 3788)
└─ sqlwriter.exe (PID 3812)
└─ sshd.exe (PID 3828)
└─ svchost.exe (PID 3856)
└─ mqsvc.exe (PID 3872)
└─ svchost.exe (PID 3880)
└─ svchost.exe (PID 3904)
└─ MsMpEng.exe (PID 3948)
└─ WindowsAzureGuestAgent.exe (PID 3976)
└─ svchost.exe (PID 3992)
└─ svchost.exe (PID 3984)
└─ svchost.exe (PID 4088)
└─ wslservice.exe (PID 4120)
└─ SMSvcHost.exe (PID 4960)
└─ vmcompute.exe (PID 5044)
└─ svchost.exe (PID 5116)
└─ svchost.exe (PID 4288)
└─ svchost.exe (PID 5956)
└─ svchost.exe (PID 5412)
└─ svchost.exe (PID 6096)
└─ svchost.exe (PID 5128)
└─ svchost.exe (PID 856)
└─ svchost.exe (PID 6720)
└─ svchost.exe (PID 8040)
└─ svchost.exe (PID 7652)
└─ svchost.exe (PID 732)
└─ svchost.exe (PID 8576)
└─ svchost.exe (PID 8392)
└─ SecurityHealthService.exe (PID 8816)
└─ svchost.exe (PID 6080)
└─ svchost.exe (PID 1972)
└─ svchost.exe (PID 3300)
└─ svchost.exe (PID 6456)
└─ msdtc.exe (PID 5360)
└─ svchost.exe (PID 6268)
└─ svchost.exe (PID 6240)
└─ svchost.exe (PID 3924)
└─ svchost.exe (PID 7796)
└─ svchost.exe (PID 11720)
└─ sppsvc.exe (PID 12800)
└─ svchost.exe (PID 13952)
└─ TrustedInstaller.exe (PID 15172)

Started: 9 minutes ago (Fri 2026-02-06 16:38:05 +0000)

D:\a\win-witr\win-witr>win-witr MsMpEng.exe
Target: MsMpEng.exe
Process: MsMpEng.exe (pid 3948)
Executable Path: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.25110.6-0\MsMpEng.exe
User: SYSTEM
Command: Failed to Access (wwitr:procParamPtrRead)
Working Directory: Failed to Access (wwitr:procParamPtrRead)
RAM Usage: 172 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ MsMpEng.exe (PID 3948)

Started: 9 minutes ago (Fri 2026-02-06 16:38:10 +0000)

D:\a\win-witr\win-witr>win-witr powershell.exe
Error: Could not find process with name powershell.exe.

D:\a\win-witr\win-witr>win-witr Runner.Listener.exe
Target: Runner.Listener.exe
Process: Runner.Listener.exe (pid 8196)
Executable Path: C:\actions-runner\cached\bin\Runner.Listener.exe
User: runneradmin
Command: C:\actions-runner\cached\bin\Runner.Listener.exe run
Working Directory: C:\Windows\system32
RAM Usage: 70 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ Runner.Listener.exe (PID 8196)
└─ Runner.Worker.exe (PID 8892)

Started: 1 minutes ago (Fri 2026-02-06 16:46:23 +0000)

D:\a\win-witr\win-witr>win-witr cmd.exe
Target: cmd.exe
Process: cmd.exe (pid 3900)
Executable Path: C:\Windows\System32\cmd.exe
User: runneradmin
Command: C:\Windows\system32\cmd.exe /c ""D:\a\win-witr\win-witr\tests\process\process.bat""
Working Directory: D:\a\win-witr\win-witr
RAM Usage: 6 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ Runner.Listener.exe (PID 8196)
└─ Runner.Worker.exe (PID 8892)
└─ pwsh.exe (PID 2796)
└─ cmd.exe (PID 3900)
└─ win-witr.exe (PID 17360)

Started: 0 seconds ago (Fri 2026-02-06 16:47:36 +0000)

D:\a\win-witr\win-witr>win-witr pwsh.exe
Target: pwsh.exe
Process: pwsh.exe (pid 2796)
Executable Path: C:\Program Files\PowerShell\7\pwsh.exe
User: runneradmin
Command: "C:\Program Files\PowerShell\7\pwsh.EXE" -command ". 'D:\a_temp\ac3abcca-850a-4d41-8f52-51cc4d24116a.ps1'"
Working Directory: D:\a\win-witr\win-witr
RAM Usage: 97 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ Runner.Listener.exe (PID 8196)
└─ Runner.Worker.exe (PID 8892)
└─ pwsh.exe (PID 2796)
└─ cmd.exe (PID 3900)

Started: 35 seconds ago (Fri 2026-02-06 16:47:01 +0000)

D:\a\win-witr\win-witr>win-witr Runner.Worker.exe
Target: Runner.Worker.exe
Process: Runner.Worker.exe (pid 8892)
Executable Path: C:\actions-runner\cached\bin\Runner.Worker.exe
User: runneradmin
Command: "C:\actions-runner\cached\bin\Runner.Worker.exe" spawnclient 1908 1920
Working Directory: C:\actions-runner\cached\bin
RAM Usage: 97 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ Runner.Listener.exe (PID 8196)
└─ Runner.Worker.exe (PID 8892)
└─ conhost.exe (PID 2756)
└─ pwsh.exe (PID 2796)

Started: 1 minutes ago (Fri 2026-02-06 16:46:24 +0000)

D:\a\win-witr\win-witr>win-witr hosted-compute-agent
Target: hosted-compute-agent
Process: hosted-compute-agent (pid 1348)
Executable Path: C:\ProgramData\GitHub\HostedComputeAgent\hosted-compute-agent
User: runneradmin
Command: "C:\ProgramData\GitHub\HostedComputeAgent\hosted-compute-agent"
Working Directory: C:\Windows\system32
RAM Usage: 18 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ conhost.exe (PID 1780)
└─ provjobd.exe3537235063 (PID 3640)
└─ Runner.Listener.exe (PID 8196)

Started: 8 minutes ago (Fri 2026-02-06 16:39:12 +0000)
Running test: D:\a\win-witr\win-witr\tests\process\provdjob.bat
Found: provjobd.exe3537235063
Target: provjobd.exe3537235063
Process: provjobd.exe3537235063 (pid 3640)
Executable Path: C:\Users\RUNNER1\AppData\Local\Temp\provjobd.exe3537235063
User: runneradmin
Command: C:\Users\RUNNER
1\AppData\Local\Temp\provjobd.exe3537235063
Working Directory: C:\ProgramData\GitHub\HostedComputeAgent
RAM Usage: 16 MB

Why It Exists:
wininit.exe (PID 836)
└─ services.exe (PID 960)
└─ svchost.exe (PID 2700)
└─ hosted-compute-agent (PID 1348)
└─ provjobd.exe3537235063 (PID 3640)

Started: 8 minutes ago (Fri 2026-02-06 16:39:16 +0000)

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 6, 2026

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Awesome! 🎉 The RAM usage feature is working beautifully! Here are some really cool insights from your test output:

Fascinating Memory Patterns

Kernel Pseudo-Processes:

  • System (PID 4): Only 172 KB! The core Windows kernel is incredibly lightweight
  • Registry (PID 132): 68 MB - makes sense since it's caching the entire Windows registry in memory
  • Even when other info fails (wwitr:procParamPtrRead), you still get RAM usage - super useful!

Heavyweight vs. Lightweight:

  • MsMpEng.exe (Windows Defender): 172 MB - the most memory-hungry process, constantly scanning
  • explorer.exe: 163 MB - the Windows shell UI
  • smss.exe (Session Manager): Just 1 MB - the bootstrap process is tiny!
  • win-witr itself: Only 4 MB - your tool is super lean! 💪

GitHub Actions Infrastructure:

  • Runner.Worker.exe: 97 MB
  • Runner.Listener.exe: 70 MB
  • pwsh.exe: 97 MB (PowerShell 7)
  • The entire CI pipeline is visible with memory footprint!

Critical System Services:

  • lsass.exe: 32 MB (handles authentication)
  • services.exe: 11 MB (manages all Windows services)
  • svchost.exe: 34 MB (hosts multiple Windows services)

Why This Is So Useful

Now you can:

  1. Debug memory leaks - run win-witr periodically to track if a process is growing
  2. Compare process footprints - see which tools/shells use more RAM
  3. Identify resource hogs - spot which processes are consuming the most memory
  4. Monitor even protected processes - GetProcessMemoryInfo works even when PEB reading fails!

The fact that you get RAM info for System and Registry (where everything else fails) is particularly valuable - it proves the process exists and shows its memory footprint even when access is heavily restricted.

Great feature addition! 🚀


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-31T18:25:04.458Z
Learning: In the supervoidcoder/win-witr repository, the user successfully implemented PEB (Process Environment Block) reading functionality to extract process command lines directly from process memory. This involves using NtQueryInformationProcess to get the PEB base address, reading PROCESS_BASIC_INFORMATION, then reading RTL_USER_PROCESS_PARAMETERS at offset 0x20 from the PEB, and finally reading the CommandLine UNICODE_STRING at offset 0x70. The implementation works for x64 Windows processes.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:43.760Z
Learning: In supervoidcoder/win-witr, the user successfully implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T17:13:13.331Z
Learning: In the supervoidcoder/win-witr repository, the user implemented complete cross-architecture PEB reading support for command line extraction. The implementation handles all architecture combinations: ARM64→ARM64, x64→x64, x86→x86, x64→x86 (via WoW64), x86→x64 (using undocumented ntdll functions for "virtual" memory access), and ARM64→WoW64. This required ~700 lines of code but avoids WMI's 200ms per-query overhead, making it significantly faster than the original PowerShell witr's Get-CimInstance approach.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 60
File: .github/workflows/build.yml:75-80
Timestamp: 2026-02-03T04:17:02.875Z
Learning: In supervoidcoder/win-witr, some batch test files in tests/ are designed to test error cases (e.g., `win-witr System` testing that the System pseudo-process correctly fails because it has no executable path or command line). These tests intentionally exit with non-zero codes, so the CI workflow does not check $LASTEXITCODE after running tests to avoid breaking CI on expected failures.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T01:58:35.174Z
Learning: In the supervoidcoder/win-witr repository, the user optimized the process tree walking algorithm from O(n²) to O(n) by taking a single CreateToolhelp32Snapshot at the start instead of creating a new snapshot for each level. This resulted in a ~4x performance improvement (from ~1000ms to ~248ms for 100-level deep trees). The optimization is validated by automated stress tests in CI that create 100-level deep alternating PowerShell/CMD process chains.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-01-30T00:59:04.068Z
Learning: In the supervoidcoder/win-witr repository, the tool implements context-aware error handling that detects which shell (PowerShell, CMD, WSL, Git Bash, Windows Terminal, Explorer) spawned the process and provides tailored error messages and recovery suggestions specific to that environment.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

@supervoidcoder supervoidcoder merged commit 5d19ff7 into main Feb 6, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant