200 character CMD output bug

Forums Desktop Info 200 character CMD output bug


Viewing 1 reply thread
  • Author
    • #3874

      Windows 10 20H2
      DesktopInfo 2.10.2, also tested and observed on 2.10.1

      I observed a weird bug with the CMD item. When the stdout output has exactly 200 characters, DesktopInfo can’t display it or assign it to a variable. Also subsequent CMD items and other items with refresh interval don’t work anymore, and changes to the INI file aren’t noticed anymore. Basically DesktopInfo is broken for any dynamic items then (I think). I’m not sure whether 200 is the only problematic character number, but 199 and 201 seem to work fine.

      Here is a simple example to reproduce the issue:

      CMD=active:1,file:powershell.exe,parameters:'This line has 199 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
      CMD=active:1,file:powershell.exe,parameters:'This line has 201 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
      CMD=active:1,file:powershell.exe,parameters:'This line has 200 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
      CMD=active:1,file:powershell.exe,parameters:'This is another line but after the 200 character line CMD items dont work anymore in DesktopInfo' | Write-Host -NoNewline
      • This topic was modified 4 days, 8 hours ago by AvatarBender. Reason: code block formatting
    • #3877

      200 is the magic number. I set the read buffer to 200 bytes. If the stdout pipe contains exactly 200 bytes, it reads it in then stalls on the next read when the pipe contains zero bytes. It’s supposed to return with a result of zero bytes read. That’s a bug in the ReadFile win32 api function. I’ve added a check for the pipe contents before attempting to read it.

Viewing 1 reply thread
  • You must be logged in to reply to this topic.
Glenn's Page