200 character CMD output bug

Forums Desktop Info 200 character CMD output bug

Tagged: 

Viewing 1 reply thread
  • Author
    Posts
    • #3874
      AvatarBender
      Participant

      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
      0
    • #3877
      GlennGlenn
      Keymaster

      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.

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