Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

wrong uptime

i've got one device with wrong uptime 

the uptime the pdq is showing is 36241 days

 

the device was rebooted a few times but still the uptime not changing

 

how can i fix it?

0

Comments

10 comments
Date Votes
  • What does Inventory show for Boot Time on that computer? You can find it by opening the computer, going to the Computer tab, then looking under General. If it says 1923, then the clock is wrong on that computer.

    0
  •  

     

    but the real uptime is 6 days

    0
  • Ah, the clock is set to the future, not the past. That makes more sense :)

    Still, the clock on that computer is wrong, or at least was when it booted. That's not Inventory's fault.

    Also, make sure fast startup is disabled: https://www.windowscentral.com/how-disable-windows-10-fast-startup

    0
  • i checked the time and it's the correct time

    also fast startup is disabled

    0
  • You've confirmed the date/time in the BIOS setup screen is correct?

    If your computer's hardware clock (i.e. in BIOS setup) is that far in the future and your OS changes the time after boot the calculated TotalDays value would show in the negative.

    PDQ Inventory likely displays that in the absolute since a negative number wouldn't be logical.

    See what this code shows in a PowerShell prompt on the problem PC:

    $td = ((get-date) – (gcim Win32_OperatingSystem).LastBootUpTime).TotalDays
    [Math]::Round([Math]::Abs($td))
    0
  • Some of my servers already installed the .Net 4.8 but not Asp.Net. Still, the update shows incorrectly in PDQ. As checked in Task Manager it shows the correct value. I don't see any Fast Start-up option in Server 2016, 2022.

    This issue starts raising after upgrading the server from 2012 to 2016 to 2019 to 2022...

    Also, some of the 2022 servers are reflecting the correct value in PDQ

    PDQ scan profile set for 5 hours intervals and 24hrs interval 

    Boot time on PDQ shows when was the machine added into PDQ. 
    As per the PowerShell Boot Time shows correct only not sure where am missing! 

    Around 35 servers are having this issue.  

    I tried the previous community discussions about Uptime. it's not helped me

    0
  • I saw your message in Discord, but will share my response here as well:

    One common thing that tends to interfere with PDQ Inventory showing the correct boot time is if the target has Fast Startup enabled.  We often see this cause incorrect boot times as the system will not perform a full shutdown with this enabled, but rather briefly go into a hibernation state.  You can disable Fast Startup by going through the following: Control Panel > Power Options > Additional power settings > Choose what the power button does > Change settings that are currently unavailable > Uncheck 'Turn on fast startup'.  If hibernation is already disabled, Fast Startup should be disabled as well since it relies on hibernation.
     
    PDQ Inventory will attempt to get uptime/latest boot-up time from the Event Log by looking up System 6009 events or by checking WMI.

    • If System 6009 events are detected, PDQ Inventory will use the one with the most recent date/time.
    • If no events are detected, PDQ Inventory will resort to referring to the WMI LastBootUpTime.

     

     
    To narrow down the issue, we recommend checking the following:

    • For these particular devices, do you see any System 6009 events?  If so, are there any events that indicate that a reboot has occurred since the boot time shown in PDQ Inventory?
    • If you run Get-CimInstance -ClassName win32_operatingsystem | select csname, lastbootuptime in PowerShell, does the boot time differ than what's in PDQ Inventory?
    • When checking the points above, if there are any instances where the data on the target doesn't match what's in PDQ Inventory,
      • send us a screenshot of what you see on the target
      • send us a screenshot of what you see in PDQ Inventory for that device
      • provide a screenshot of the "Scans" page for that device in PDQ Inventory

     
    If the information in the WMI database is incorrect, there could be some WMI corruption on those targets.  Please check out our WMI Diagnostics knowledge base article, specifically the Recommended Fixes section.

    0
  • I am having this issue with 1 machine as well. Uptime is 1439 days with a boot time in the future(7/3/2027).

    Windows time is correct:
    The current date is: Tue 07/25/2023

    BIOS Time is correct:
    Day=25
    DayOfWeek=2
    Hour=8
    Milliseconds=
    Minute=55
    Month=7
    Quarter=3
    Second=28
    WeekInMonth=5
    Year=2023

    Event Log for 6009 time is correct:

    ProviderName: EventLog

    TimeCreated             Id LevelDisplayName Message                                                     
    -----------             -- ---------------- -------                                                     
    7/25/2023 8:18:58 AM  6009 Information      Microsoft (R) Windows (R) 10.00. 19045  Multiprocessor Free.
    7/25/2023 8:17:47 AM  6009 Information      Microsoft (R) Windows (R) 10.00. 19045  Multiprocessor Free.
    7/25/2023 7:30:09 AM  6009 Information      Microsoft (R) Windows (R) 10.00. 19045  Multiprocessor Free.
    7/24/2023 4:21:13 PM  6009 Information      Microsoft (R) Windows (R) 10.00. 19045  Multiprocessor Free.
    7/14/2023 8:17:20 AM  6009 Information      Microsoft (R) Windows (R) 10.00. 19045  Multiprocessor Free.

    Hiberboot is confirmed disabled:
    $fastStartupEnabled = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power' -Name 'HiberbootEnabled' | Select-Object -ExpandProperty 'HiberbootEnabled'
    $fastStartupEnabled
    0

    Have rebooted a few times.

    Any other suggestions?

    0
  • I'd try just deleting the computer from PDQ Inventory and then add it back.

    0
  • Just tested, unfortunately after a new scan it came back with the same results. 
    Thanks for the suggestion though.

    0