We appreciate the contributions many of you have been able to make towards repairing the storm damage and keeping a roof over our heads. With your help we’ve been able to complete much of the critical work. There is still work to be done to secure the house and your continued support will be a huge help.
Guests have read-only access to our forums. If you wish to participate you will need to register. Be sure to activate your account from the email sent to you when you register.
Updated from v3.13.2 to v3.14.0 and had the application hand. Debug log below.
7/14/2024 13:55:57:627 INFO Desktop Info version 3.14.0.4578
7/14/2024 13:55:57:627 INFO Windows version 10.0.22631
7/14/2024 13:55:57:627 INFO Path: C:\Users\username\AppData\Local\DesktopInfo\
7/15/2024 07:07:18:770 ERROR STACK DUMP
7/15/2024 07:07:18:751 UI [TDesktopInfoMainForm.EndUpdate]
7/15/2024 07:07:18:751 DEBUG [GarbageCollection]
7/15/2024 07:07:18:751 UI [TDesktopInfoMainForm.DoUpdate]
7/15/2024 07:07:18:761 DEBUG [GetDosOutput] 99 bytes available
7/15/2024 07:07:18:761 DEBUG [GetDosOutput] Reading 200 bytes
7/15/2024 07:07:18:761 DEBUG [GetDosOutput] Read 99 bytes
7/15/2024 07:07:18:761 DEBUG [GetDosOutput] 0 bytes available
7/15/2024 07:07:18:761 DATA [GetDosOutput] wan_ipv4 , wan_rdns , wan_ipv6
ipv4_result , rdns_result , ipv6_result (hidden for security)
7/15/2024 07:07:18:761 TIMING [DoProc] cmd2 (time: 11211766ms)
7/15/2024 07:07:18:762 ERROR [GetItemDataThreaded] cmd2 thread timeout
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.
I spent most of Wednesday going over that threading code and made some changes. I'm not happy with that big timing number so I've rewritten the timing code.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.
So you put a timeout on the actual powershell command rather than a thread-timeout on the DTI CMD ? This avoids the DTI timeout code from executing. What would be an interesting test now would be to remove your timeout from the powershell command and put a really short thread-timeout on the CMD item to force the DTI timeout code to run.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.