Microsoftevvivame : the problem is that tasklist isn't reporting the name of the 16-bit module - it's reporting the window title of its top-level window. For code to enumerate windows and their titles, it must be running in the same TS session and desktop as the windows/titles it's enumerating. In your example, PsExec is running tasklist.exe in session 0, not in the interactive desktop where ntvdm.exe is emulating 16-bit processes.
Issue with PSExec + Tasklist?
As you know, the NTVDM is an emulator to run 16bit app on Windows 32bit
I use this, as minimal, test.bat:
for /F "tokens=1,2" %%i in ('tasklist /FI "IMAGENAME eq NTVDM.EXE" /fo table /nh') do set pid=%%j
tasklist.exe /v | find /i "%PID%" > Tasklist.txt
After run test.bat on my PC, the Tasklist.txt contains the correct value:
ntvdm.exe 3484 Console 1 24.896 K Running PESA\Ciro 0:00:05 SILVA
Where SILVA is the 16bit module name.
If I execute test.bat with PSExec \\xx.xx.xx.xx -u Ciro -p yyyy, I found in Tasklist.txt an incorrect content like this:
ntvdm.exe 3484 Console 1 24.900 K Unknown PESA\Ciro 0:00:05 N/D
As you can see the 16bit module name (SILVA) is loss !!
Some suggestion?
Thanks
I've noticed one strange thing in TCPView.
When enabling the address resolution option, IPv4 addresses are displayed in place of the original IPv6 ones.
Here's the output when address resolution is not enabled
and here's the output when address resolution is enabled.
I ran into a really bizarre piece of behavior with PsExec... When configuring a Threadripper PRO 5975WX in the 4x NUMA node mode with L3 as SRAT, one of my non-numa-aware pieces of software (Ultra Fractal) was defaulting to the 4th node most of the time, only giving itself access to 16 cores. If I forced it to the first node, it would still only use 32/64 cores; affinity couldn't be set to all-core because the program itself (as verified with the author) was only using a 32-bit affinity mask.
Since the initial node assignment was unpredictable I decided to use PSExec to run it on the local machine and force it to start on the first CPU and at least get 32 cores reliably, and oddly enough it ran with affinity on 63/64 cores across the 4 nodes. This is on Windows 10 Pro Workstation so the kernel patches of Win 11 that auto-distribute weren't there. Seemed very odd. Additionally when I eventually turned off the L3 as SRAT feature for now due to lack of software that cared about NUMA (except x265, which works just as well without it) and ran with the old shortcut, the affinity was locked to the first core instead. Not sure why this happened but it was a good workaround. It would be interesting to see results from software like this from a 64/128 core system on Windows 10 with CPU groups or a system with two physical CPUs.
Good Morning,
There is a bug in TCPView v4.19 in 32/64 bit.
I can't see all TCP v4 traffics inbound and/or outbound. I can see with the command netstat.
It works with the previous version of the tool.
Thanks for your feedback.
Best Regards,
Sébastien VIATOUR
