News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

When was a program last run

Started by Magnum, January 18, 2013, 03:59:17 AM

Previous topic - Next topic

Magnum

I am doing some file cleanup.

I am trying to find out when a program was run last.

I have Microsoft Visual C 2010 x86 Redistributable and would like to know if it is being used at all.

If I don't need it and it's not being used by something else, I will delete it.

I used appwiz.cpl and had it list by last day used, but many programs that have been recently used are not listed.

The programs that windows does track are only looked at for the last 30 days. Can that be increased ?

I could look to see if there are new entries in the program's folders, but that would be very time consuming.

I am looking for some suggestions.

Thanks,
              Andy





Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

CommonTater

Depending on your NTFS settings, you should be able to use GetFileAttributesEx() to fetch the last access time of any file on your system.  If you are looking for lists, you can get the same information from FindFirstFile() and FindNextFile() as well.

I say "depending" because there is a registry tweak that turns this off...  The default is ON.


dedndave

i use AttributeChanger from Romain Petges

http://www.petges.lu/home/download/

you can right-click on a file - Change Attributes
you can view the current times (you don't have to change them)

Magnum

I think you are misunderstanding what I am looking for.

I will think of a better way of explaining.

Andy
Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

jj2007

Quote from: dedndave on January 18, 2013, 05:55:37 AM
you can view the current times (you don't have to change them)

Not sure whether last access time is a reliable indicator. When you right-click on a file in Explorer to see "Properties", most of the time it tells you the document has been accessed - right now...

HKEY_USERS\xxx\Software\Microsoft\Windows\ShellNoRoam\MUICache might be more promising.

CommonTater

Quote from: jj2007 on January 18, 2013, 07:34:51 AM
Quote from: dedndave on January 18, 2013, 05:55:37 AM
you can view the current times (you don't have to change them)

Not sure whether last access time is a reliable indicator. When you right-click on a file in Explorer to see "Properties", most of the time it tells you the document has been accessed - right now...

HKEY_USERS\xxx\Software\Microsoft\Windows\ShellNoRoam\MUICache might be more promising.

Because you accessed it *right now*...  The properties dialog (right click) does more than simply look up the directory entry, it loads the file and probes it's resources for version information, metadata and so on...   

The directory access routines (GetFileAttributesEX, FindFirstFile, FindNextFile, etc) simply look in the directory, without touching the file itself.

jj2007

Quote from: CommonTater on January 18, 2013, 07:45:53 AMThe directory access routines (GetFileAttributesEX, FindFirstFile, FindNextFile, etc) simply look in the directory, without touching the file itself.

That's technically correct but unfortunately pretty irrelevant. Here is an excerpt of my Program Files access stats:
17.01.2013  21:18:09    C:\Programmi\Mozilla Firefox\plugin-container.exe
17.01.2013  21:06:27    C:\Programmi\Mozilla Firefox\firefox.exe
17.01.2013  21:05:58    C:\Programmi\Mozilla Thunderbird\thunderbird.exe
...
13.01.2013  02:10:23    C:\Programmi\CDBurnerXP\unins000.exe
13.01.2013  02:10:22    C:\Programmi\KompoZer\unins000.exe
13.01.2013  02:10:21    C:\Programmi\QtWeb\unins000.exe
13.01.2013  02:10:21    C:\Programmi\Xvid\uninstall.exe
13.01.2013  02:10:14    C:\Programmi\Winspector\unins000.exe
13.01.2013  02:10:14    C:\Programmi\WinID\Uninstall.exe


Guess what I did on 13 January two hours after midnight?

The proggie is attached - test yourself. The source is also there, but if you assemble it, the resulting exe will display last write time, not access (I temporarily modified the library to get access times).

CommonTater

jj ... NTFS stores file dates and times as UTC ... To get your local time from them you need to use FileTimeToSystemTime() or similar functions to translate your offset and any daylight savings offsets for you... Where I am 2:00am UTC would be 10:00pm the day before...

It's not irrelevent... if you know how to use it.

Magnum

What do you mean by write time ?

Does access mean any time the program was started ?

Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

Magnum

IDA was opened twice and here is what your program came up with.

Andy

I think we may have to look at the registry at some point. ??

1/4/ 9:00:45 AM   C:\Program Files\IDA Free\idag.exe


About 15 minutes later
-------------------------------------------
1/4/2013  9:00:46 AM   C:\Program Files\IDA Free\wingraph32.exe
1/4/2013  9:00:45 AM   C:\Program Files\IDA Free\idag.exe
Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

Magnum

http://nirsoft.net/utils/computer_activity_view.html

Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

jj2007

Quote from: CommonTater on January 18, 2013, 08:36:41 AM
jj ... NTFS stores file dates and times as UTC ... To get your local time from them you need to use FileTimeToSystemTime() or similar functions to translate your offset and any daylight savings offsets for you... Where I am 2:00am UTC would be 10:00pm the day before...

It's not irrelevent... if you know how to use it.

Oh really, Tater?? ::)

Just in case you know how to use a debugger, put an int 3 here:
        For_ ebx=0 To eax-1
                int 3
                PrintLine GfDate$(ebx), Spc2$, GfTime$(ebx), Tb$, Files$(ebx)
        Next

After a while, you will stumble over this:
00401EC4        ³.  56                        push esi                                ; ÚLocalFileTime
00401EC5        ³.  50                        push eax                                ; ³FileTime = 14F6D0 -> {LowDateTime=353B6AD4,HighDateTime=1CDEC5D}
00401EC6        ³.  E8 B52B0000               call <jmp.&kernel32.FileTimeToLocalFile ; ÀKERNEL32.FileTimeToLocalFileTime
00401ECB        ³.  8D45 E8                   lea eax, [local.6]
00401ECE        ³.  50                        push eax                                ; ÚSystemTime
00401ECF        ³.  56                        push esi                                ; ³FileTime
00401ED0        ³.  E8 B12B0000               call <jmp.&kernel32.FileTimeToSystemTim ; ÀKERNEL32.FileTimeToSystemTime


My dearest friend Tater, the file times are correct, and on 13 January two hours after midnight, I was sleeping. But Microsoft Security Essentials was not sleeping. Therefore, your proposal to use access times is irrelevant (with an "a", not an "e").

CommonTater

Quote from: Magnum on January 18, 2013, 08:37:55 AM
What do you mean by write time ?

Does access mean any time the program was started ?

Windows direstories keep 3 timestamps for each file...

Creationtime ... when the file was first written to your disk. 
LastAccessTime ... the last time the file was READ.
LastWriteTime ...   the last time the file was WRITTEN to (modified)

So if you had a text file, you were working on ... CreationTime would reflect the day/time you first saved the file, LastAccessTime would reflect the last time you loaded it into your editor, LastWriteTime would tell you the last time you saved the file.

Since executable files don't get written to, you want the LastAccessTime which will tell you when it was last loaded by the system.

You can get date/time information from a few different functions in the Windows API ... FindFirstFile, FindNextFile, GetFileAttributesEx, GetFileTime etc. 

These time stamps are stored in UTC format (basically the number of seconds since January 1, 1980, Grenich Mean Time) so you will need to convert them to your local time using functions such as FileTimeToLocalFileTime and FileTimeToSystemTime, etc. 

Since these are a simple 64bit integer value, you can compare them easily enough to find which is older or newer... So if you were looking for files that haven't been accessed for (say) 6 months all you need to do is prepare a timestamp that is 6 months old using a function such as SystemTimeToFileTime then run through each folder with FindFirstFile and FindNextFile checking the LastAccessTimes...

Here's the scoop from MSDN ...  http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

CommonTater

Quote from: jj2007 on January 18, 2013, 09:18:21 AM
Quote from: CommonTater on January 18, 2013, 08:36:41 AM
jj ... NTFS stores file dates and times as UTC ... To get your local time from them you need to use FileTimeToSystemTime() or similar functions to translate your offset and any daylight savings offsets for you... Where I am 2:00am UTC would be 10:00pm the day before...

It's not irrelevent... if you know how to use it.

Oh really, Tater?? ::)

Just in case you know how to use a debugger, put an int 3 here:
        For_ ebx=0 To eax-1
                int 3
                PrintLine GfDate$(ebx), Spc2$, GfTime$(ebx), Tb$, Files$(ebx)
        Next

After a while, you will stumble over this:
00401EC4        ³.  56                        push esi                                ; ÚLocalFileTime
00401EC5        ³.  50                        push eax                                ; ³FileTime = 14F6D0 -> {LowDateTime=353B6AD4,HighDateTime=1CDEC5D}
00401EC6        ³.  E8 B52B0000               call <jmp.&kernel32.FileTimeToLocalFile ; ÀKERNEL32.FileTimeToLocalFileTime
00401ECB        ³.  8D45 E8                   lea eax, [local.6]
00401ECE        ³.  50                        push eax                                ; ÚSystemTime
00401ECF        ³.  56                        push esi                                ; ³FileTime
00401ED0        ³.  E8 B12B0000               call <jmp.&kernel32.FileTimeToSystemTim ; ÀKERNEL32.FileTimeToSystemTime


My dearest friend Tater, the file times are correct, and on 13 January two hours after midnight, I was sleeping. But Microsoft Security Essentials was not sleeping. Therefore, your proposal to use access times is irrelevant (with an "a", not an "e").

So, what you're telling me is that the system accurately recorded activity that was occuring while you slept. 

Y'know what... I'm getting real tired of you.  You pulled this same crap on Pelle's Forums as well.  I don't know what particular bee you've got in your bonnet but you certainly aren't going to make any friends going into a C forum touting your ASM expertise in a constant string of contraditions then finally admitting you've never actually written C code ....  And you're not going to win my favour over here by going out of your way to contradict me every chance you get.  I strongly suggest you get some help for this character flaw before it really messes up your life.

Here's a hint .... you could have been right and you could have given the OP valuable information if you had simply pointed out that some background tasks may alter the LastAccess timestamp.  In fact, I would have thanked you for adding that.  But you tried to use it as a way to prove me wrong... which is going to do nothing but piss me off.

sinsi

Well, looking at the files in system32, I last accessed them (a few) on the 12th of January, most were last year.
I would imagine that the kernel has better things to do than update the access time when it loads a dll or exe.
🍺🍺🍺