The CMD item seems to have timed out after going back in time.  Is that the end of the log?

Yes, that was the only entry. I was able to right-click Quit, but that took quite some time actually complete. I rolled back to v3.13.2 for the time being, to help with stability.

can you post the CMD in question please.

See code block below.

SET-SECTION=key:wan-ip-lookup,value:wan-ip-lookup.ps1

CMD=interval:300,color:55cc77,text:WAN Address,onload,no-wait:2,thread-timeout:60,read-as-csv:1,csv-header:1,file:powershell.exe, parameters:-Command "& { %wan-ip-lookup% }",trim:1,show-window:0,hide-no-result:1, display:{{{IPv4: %wan_ipv4%}}}{{{   IPv6: %wan_ipv6%}}}{{{ |Reverse DNS: %wan_rdns%}}}

[wan-ip-lookup.ps1]
## Output headers
Write-Host wan_ipv4 ',' wan_rdns ',' wan_ipv6

Try { $IPv4_addr = (Invoke-RestMethod -Uri  https://4.tnedi.me/  -UseBasicParsing -ErrorAction "Stop") }
	Catch { Try { $IPv4_addr = (Invoke-RestMethod -Uri  https://ip4.seeip.org/  -UseBasicParsing -ErrorAction "Stop") }
		Catch { $IPv4_addr = 'n/a' }
	}
Try { $IPv6_addr = (Invoke-RestMethod -Uri  https://6.tnedi.me/  -UseBasicParsing -ErrorAction "Stop") }
	Catch { Try { $IPv6_addr = (Invoke-RestMethod -Uri  https://ip6.seeip.org/  -UseBasicParsing -ErrorAction "Stop") }
		Catch {	$IPv6_addr = 'n/a' }
	}
Try {
		$IPv4_rdns = (Invoke-RestMethod -Uri  https://ipinfo.io/$IPv4_addr/hostname  -UseBasicParsing -ErrorAction "Stop").Trim()
		If ( -not $IPv4_rdns ) { $IPv4_rdns = 'No record found' }
    }
	Catch { $IPv4_rdns = 'n/a' }

Write-Host $IPv4_addr ',' $IPv4_rdns ',' $IPv6_addr
Exit 0

thanks.  just tried it, returned within 2 seconds without error.

I can see a possible contention if the thread times out. can you try it with a much reduced "thread-timeout" setting and maybe a separate test with no threading.

That timing number looks awfully big...

I've just added a timeout value to the Invoke-RestMethod command in the PS1 section, limiting each attempt to 10s. That should keep the script under the 60s thread-timeout period. Let me update to v3.14 again and see what I get.

So far so good. Last time it glitched it wasn't immediate, so I'll continue to monitor.

Posted by: @nathan_k

↑

So far so good. Last time it glitched it wasn't immediate, so I'll continue to monitor.

I've also made a bunch of other optimizations which I'll be testing over the next week.

Still no issues. Looks like adding timeouts to the Invoke-RestMethod helped to resolve the issue. Interested to see how your threading code changes will affect things. Thanks for all your help, as usual.

Posted by: @nathan_k

↑

Still no issues. Looks like adding timeouts to the Invoke-RestMethod helped to resolve the issue. Interested to see how your threading code changes will affect things. Thanks for all your help, as usual.

@glenn I actually put it in both. I added it to the CMD item, with a timeout just longer than if I added all the individual timeouts in the script together. CMD got thread-timeout:60 and each of the Invoke-RestMethod commands got a -TimeoutSec 10 added to it.

CMD=interval:300,color:55cc77,text:WAN Address,onload,no-wait:2,thread-timeout:60,read-as-csv:1,csv-header:1,file:powershell.exe, \
  parameters:-Command "& { %wan-ip-lookup% }",trim:1,show-window:0,hide-no-result:1, \
  display:{{{IPv4: %wan_ipv4%}}}{{{   IPv6: %wan_ipv6%}}}{{{ |Reverse DNS: %wan_rdns%}}}

[wan-ip-lookup.ps1]
## v1.0 -- Retrieve IPv4, IPv6 and Reverse DNS for IPv4
## v1.1 -- Updated to use Invoke-RestMethod instead of Invoke-WebRequest
## v1.2 -- Added secondary Uri for IPv4 and IPv6

## Output headers
Write-Host wan_ipv4 ',' wan_rdns ',' wan_ipv6

Try { $IPv4_addr = (Invoke-RestMethod -Uri  https://4.tnedi.me/  -UseBasicParsing -TimeoutSec 10 -ErrorAction "Stop") }
	Catch { Try { $IPv4_addr = (Invoke-RestMethod -Uri  https://ip4.seeip.org/  -UseBasicParsing -TimeoutSec 10 -ErrorAction "Stop") }
		Catch { $IPv4_addr = 'n/a' }
	}
Try { $IPv6_addr = (Invoke-RestMethod -Uri  https://6.tnedi.me/  -UseBasicParsing -TimeoutSec 10 -ErrorAction "Stop") }
	Catch { Try { $IPv6_addr = (Invoke-RestMethod -Uri  https://ip6.seeip.org/  -UseBasicParsing -TimeoutSec 10 -ErrorAction "Stop") }
		Catch {	$IPv6_addr = 'n/a' }
	}
Try {
		$IPv4_rdns = (Invoke-RestMethod -Uri  https://ipinfo.io/$IPv4_addr/hostname  -UseBasicParsing -TimeoutSec 10 -ErrorAction "Stop").Trim()
		If ( -not $IPv4_rdns ) { $IPv4_rdns = 'No record found' }
    }
	Catch { $IPv4_rdns = 'n/a' }

Write-Host $IPv4_addr ',' $IPv4_rdns ',' $IPv6_addr
Exit 0

@nathan_k I've been noticing a thing lately. Every so often a WMI query that should take a few milliseconds to execute is taking 2 minutes or so. This is nothing to do with Desktop Info. The exact same query that takes 2 minutes to return will, on the next iteration, take 9ms to return and it's not consistent.  I'm convinced Windows has introduced some bug in the WMI system.

I don't like making a query threaded if I don't have to because it's unnecessary overhead but it seems that's the only solution to avoid DTI locking up indefinitely.

I'm going to add some fail-safe code that will monitor the collector thread and take action if it hasn't been seen for a while.