setupapi.offline.log

I have been advised as follows by one of our own people (not the 3rd party)

Sometimes the Image is done via PXE/SCCM, sometimes it’s had to be done via stand alone media or a media boot USB, all of which are created by the 3rd party

There are some BIOS changes that have to be made nowadays to put the machine in to UEFI mode and secure boot is enabled too as part of that.

Not sure where that takes me.

Unless you can confirm there is an alternative, the information below takes you to the point win7 system operated privilege access rights. Changes to the system should be outside the scope of the ordinary laptop user access to installing new SW, devices or drivers etc. on to the laptop other than those permitted by the 3rd party baked image/build.

You mentioned in your first post

There is a setupapi.offline.log which I have just started reading about but there's a 2-year gap between it's last entry and the first one in setupapi.dev.log.

And, the first entry in setupapi.offline.log in 2011 which makes no sense as the Dell warranty didn't start until 2015. We're in a corporate environment where

a 3rd party vendor tests and provides the standard images/builds.

Does your setupapi.offline.log look like this?

setupapi.offline.pdf - https://www.dropbox.com/s/gi5xjr1t0wpkxia/2011%20setupapi.offline.pdf

To avoid falling into investigation rabbit holes do you have in your possession or can you get a second DD of another similar laptop administered by the 3rd-party so you and your team can make a comparison of the .logs in question from the first laptop and see any parity with the second laptop?

Changes to the system should be outside the scope of the ordinary laptop user access to installing new SW, devices or drivers etc. on to the laptop other than those permitted by the 3rd party baked image/build.

Indeed, but all our laptop users have Local Admin rights. Don't shoot the messenger

Does your setupapi.offline.log look like this?

setupapi.offline.pdf - https://www.dropbox.com/s/gi5xjr1t0wpkxia/2011%20setupapi.offline.pdf

Nope 'fraid not.

To avoid falling into investigation rabbit holes do you have in your possession or can you get a second DD of another similar laptop administered by the 3rd-party so you and your team can make a comparison of the .logs in question from the first laptop and see any parity with the second laptop?

Re rabbitholes, absolutely agree. Re second DD image, one of my colleagues is building a new machine for me and I will make the DD image and make a comparison. However if that doesn't clear things up (and I'm not sure exactly how it would, but let's not get further into that rabbit hole), I'm quite happy to point out the discrepancy, admit that I can't account for it, and suggest that if further investigation is required then a second opinion is sought. I don't like giving up but my cup floweth over with many competing priorities (

Changes to the system should be outside the scope of the ordinary laptop user access to installing new SW, devices or drivers etc. on to the laptop other than those permitted by the 3rd party baked image/build.

Indeed, but all our laptop users have Local Admin rights. Don't shoot the messenger

Ok this is a step forward that you can corroborate this now.

Does your setupapi.offline.log look like this?

setupapi.offline.pdf - https://www.dropbox.com/s/gi5xjr1t0wpkxia/2011%20setupapi.offline.pdf

Nope 'fraid not.

Fair enough, then perhaps provide a copy of your setupapi.offline.log with the 2011 entry. Then we can see if this is a red-herring or might be a cause for genuine concern.

To avoid falling into investigation rabbit holes do you have in your possession or can you get a second DD of another similar laptop administered by the 3rd-party so you and your team can make a comparison of the .logs in question from the first laptop and see any parity with the second laptop?

Re rabbitholes, absolutely agree. Re second DD image, one of my colleagues is building a new machine for me and I will make the DD image and make a comparison. However if that doesn't clear things up (and I'm not sure exactly how it would, but let's not get further into that rabbit hole), I'm quite happy to point out the discrepancy, admit that I can't account for it, and suggest that if further investigation is required then a second opinion is sought. I don't like giving up but my cup floweth over with many competing priorities (

You have in your possession a copy of the standard image/build from the 3rd-party to do this (that is before the laptop had any use post image/build)?

I get what you are saying. Of course, not knowing the underlying issue of your case whether its about user laptop misuse, or a dispute, or something else, any info I am referring to is to deal with setup issues or errors etc.

Fair enough, then perhaps provide a copy of your setupapi.offline.log with the 2011 entry. Then we can see if this is a red-herring or might be a cause for genuine concern.

My mistake, was looking at wrong file when I replied, apologies for my sloppiness.

Yes they look similar. The first page looks the same, and there is an entry in both which is the same
<<< Section end 2011/04/12 004454.940
<<< [Exit status SUCCESS]

At that point the two files diverge.

Hope that helps

Peter

Ok, then using the .log I posted there is nothing suspicious in that .log at all. It demonstrates first installation and then additional events that occurred thereafter.

Michael Sonntag (Windows Forensics) refers to C\Windows\inf\setupapi.offline.log as "Initial installation" and "Remains during an OS upgrade".

I looked at a number of setupapi.offline.logs and all had entries prior to the date of purchase etc… And all showed post events in-line with purchase/warranties/etc.

Yes they look similar. The first page looks the same, and there is an entry in both which is the same
&lt;&lt;&lt; Section end 2011/04/12 004454.940
&lt;&lt;&lt; [Exit status SUCCESS]

The identical timestamp might tell you something if that is in your setupapi,offline.log; that the event is common and not unusual.

You may also want to consider the whole entry and not just the section end. If this helps, a record of an event is formatted

>>> [section_title - instance_identifer]
>>> time_stamp Section start
section body log entry
section body log entry
section body log entry
<<< [time_stamp Section end]
<<< [Exit Status(status_value)]

At that point the two files diverge.

Yup, and why I asked to see your .log as I already know what is in mine.

I think Harlan's comments to you about "timeline" would be worth pursuing to sort 'wheat from the chaff' (see https://en.wikipedia.org/wiki/Matthew_312 (see analysis).

In your timeline you might think it helpful to have parameters

1) timestamps of .logs and files
2) timestamps of entries in .logs and files.

As a further observations arising from your original post

I'm now looking at a DD image of a Win7 Enterprise system where setupapi.dev.log is only 476 bytes, the first entry is dated 17th April 2019 but the computer has been in use for a lot longer than that. And the "cousin" isn't present

.logs can be set for levels of events that are logged (so to speak).

Maybe check to see if the examples entries (or similar) below are in the registry and determine the logging level values.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\LogLevel
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\AppLogLevels