Time Stamp Impossibilities RRS feed

  • Question

  • Just read the AUTORUNS chapter of Troubleshooting w/ sysinternals.

    Went to the Schedule Tasks tab of autoruns and noticed that 8 processes

    had a timestamp of 2032 and another process had 7/23/1918. How did they

    get this way and how do I change them back?

    Wednesday, August 7, 2019 6:56 PM

All replies

  • Well, there is something wrong in Autoruns..

    Comparing the output of these two commands the time/date values are completely different.

    schtasks /query /xml > c:\temp\task.xml

    autorunsc -a t > c:\temp\auto.txt

    Autoruns seems to NOT report correctly the Date field..

    Can you please post a screenshot of Autoruns and also the output from those two commands?

    Maybe Mark can have a look at this..


    Wednesday, August 7, 2019 8:26 PM
  • preface: I am unable to insert pictures or links of my data as it is saying my account is unverified with no instructions on how to get verified...I've had this account for 8 years...I have put placeholders where my images were... continue:

    I have been searching for an answer to this as well. I am an Incident Responder and I have been working on using autoruns on a network wide scale for threat hunting. I've collected about 2 million entries from autoruns and stored it in ElasticSearch and I noticed that the timestamp issues are spread fairly evenly across the last 100ish years:


    This trend also occurs about 20 years into the future as well:


    Further analysis shows that it is also fairly evenly spread across the different categories that autoruns returns as well:


    To double check that this was an error by Autoruns I exported some registry entries which autoruns identified as being from 1915 and 1988 and when I view the timestamps in the exports they come through as more realistic time stamps from earlier this year. I also ran the GUI version to confirm I was seeing the same errors and got the following:


    It appears that many of them come through correct as there is a large cluster around the last 3ish years which is what would be expected but a large portion are incorrect. I would really like to get to the bottom of what is causing this and how it can be fixed. The tool is still immensely useful but have reliable timestamps would be amazing.

    Thursday, November 7, 2019 6:44 PM
  • Thanks for reporting and for Mario for following up offline

    We added this to the backlog and I have flagged it for consideration at the next backlog review.


    Wednesday, November 13, 2019 10:08 AM