Systeminformer crashes when attempting to open file location of WSL process.

[kotenok2000]

Brief description of your issue

When i right click boinc and press "Open frile location" it crashes.

Steps to reproduce (optional)

Run ununtu on WSL1 Attempt to open bash executable location

Expected behavior (optional)

Open E:\wsl\ubuntu\rootfs\home\user\BOINC\

Actual behavior (optional)

Environment (optional)

3.1.24305.0
10.0.22631.4317

[kotenok2000]

SystemInformer_DumpFile_JHUPZSVDCHMQMQA.zip

[ge0rdi]

It crashes because processItem->FileNameWin32 is null (for some reason) and there is no check for that (FileName is checked instead): https://github.com/winsiderss/systeminformer/blob/561370ad9dafe5b5fe74fc8171e950615db0e25c/SystemInformer/mainwnd.c#L1888-L1894

The fix of the crash would be trivial (just add proper check), but there is some deeper issue as SI was unable to obtain Win32 file name for the process image.

[kotenok2000]

It worked in the past.

[kotenok2000]

Image file name is visible in properties

[ge0rdi]

It seems that General tab of process properties resolves Win32 file name on its own and doesn't use the one from processItem.

But processItem->FileNameWin32 seems to be populated when processes are enumerated: https://github.com/winsiderss/systeminformer/blob/561370ad9dafe5b5fe74fc8171e950615db0e25c/SystemInformer/procprv.c#L1202-L1205

So it is weird why it was uninitialized in your case ...

[ge0rdi]

If you enable File name column (in main window), will it show proper name in case of those WSL processes?

[kotenok2000]

No.

[ge0rdi]

So it would seem that PhGetProcessImageFileNameWin32 has some problem with resolving the file name.

General tab uses PhGetFileName as fallback (when PhGetProcessImageFileNameWin32 failed) and it seems to work in this case. Maybe we should do the same in PhpFillProcessItem when populating ProcessItem->FileNameWin32. @dmex @jxy-s