Process Lasso crashing when a program is run off of a mapped network drive

[LookHangars]

I have been able to consistently cause Process Lasso to crash by:

• Having the Process Lasso window open (list of processes displayed).
• Running a program from a mapped network drive (drive letter pointed to a network share).

Doesn't matter what program.  It crashes every time.  It points me to a crash dump location.  (146 MB dump, a little big to upload here.)

Things that do not cause it to crash:

• Running a program from a mapped network drive while Process Lasso is closed (running in system tray, no window open).
• Running a program from a network share that is NOT mapped to a drive (\\SERVERNAME\SHARENAME\file.exe) while Process Lasso is open.

I'd speculate that Process Lasso is running something either elevated or as the SYSTEM account, which would not be able to "see" the mapped network drive (mapped drives are user-specific) and it is failing to get some information about the running process because of that.

[Jeremy Collake]

I can confirm there is some issue with the GUI in this circumstance. We're still studying it.

It is possible that disabling process icons will work as a temporary mitigation. You can do that by unchecking 'View / Show Process Icons'.

I'll report back when we know more and have a fix.

Thank you!

[Jeremy Collake]

Process Lasso v12.0.4.1 BETA has a fix. The aforementioned mitigation would have also worked.

The issue was in the call to shell32.ExtractAssociatedIcon. One of its parameters, pszIconPath, is a pointer to a non-const buffer holding the pathname to retrieve the icon for. We (I) never paid much attention to it being non-const, and neither have most programmers, as virtually every example of this API, and its sibling ExtractAssociatedIconEx, on the internet is wrong in the same way.

Turns out, it's non-const for a reason: ExtractAssociatedIcon can choose an icon held in a different module than pszIconPath specifies, and in that case, it will will fill the buffer pointed to by pszIconPath with the pathname of the module it actually extracted the icon from.

For files on mapped network drives, an icon is selected from shell32.dll instead of the target executable, so the buffer is filled with shell32's pathname. If that pathname exceeded the original string length, a buffer overflow occurred.

Ultimately, it's poor API design by Microsoft, even at the time it was introduced in XP. The parameter use would have been clarified and buffer overflow prevented if the API accepted a now standard buffer size parameter. Instead, the minimum required size is presumably MAX_PATH, though the documentation doesn't specify such.

[LookHangars]

Thanks, and I appreciate the detailed explanation of the issue (as a fellow software engineer).  I will check this out soon.

[LookHangars]

Updated to 12.0.4.  Can no longer reproduce this crash.  Thanks.