"Reconfigured the Product"....

Whilst perusing the Windows System log tonight I noticed *hundreds* of
messages about this - perhaps one for every installed app.

I googled the 1035 code but it didn't make much sense to me.

Has something gone terribly wrong? Or terribly right?

Here's an example:

Log Name: Application
Source: MsiInstaller
Date: 8/19/2017 9:40:45 PM
Event ID: 1035
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer: Dad3
Description:
Windows Installer reconfigured the product. Product Name: Microsoft .NET
Framework 4.5.1 Multi-Targeting Pack. Product Version: 4.5.50932. Product
Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration
success or error status: 0.
Event Xml:
Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"
System
Provider Name="MsiInstaller" /
EventID Qualifiers="0"1035/EventID
Level4/Level
Task0/Task
Keywords0x80000000000000/Keywords
TimeCreated SystemTime="2017-08-20T01:40:45.579680500Z" /
EventRecordID1814502/EventRecordID
ChannelApplication/Channel
ComputerDad3/Computer
Security UserID="S-1-5-18" /
/System
EventData
DataMicrosoft .NET Framework 4.5.1 Multi-Targeting Pack/Data
Data4.5.50932/Data
Data1033/Data
Data0/Data
DataMicrosoft Corporation/Data
Data(NULL)/Data
Data
/Data
Binary
7B36413043363730302D454139332D333732432D383837312D 444343463133443136304134
7D303030306466326539303661656163353630643833303034 613662646535346464343634
3030303030393034/Binary
/EventData
/Event

Jason wrote:
Whilst perusing the Windows System log tonight I noticed *hundreds* of
messages about this - perhaps one for every installed app.

I googled the 1035 code but it didn't make much sense to me.

Has something gone terribly wrong? Or terribly right?

Here's an example:

Log Name: Application
Source: MsiInstaller
Date: 8/19/2017 9:40:45 PM
Event ID: 1035
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer: Dad3
Description:
Windows Installer reconfigured the product. Product Name: Microsoft .NET
Framework 4.5.1 Multi-Targeting Pack. Product Version: 4.5.50932. Product
Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration
success or error status: 0.
Event Xml:
Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"
System
Provider Name="MsiInstaller" /
EventID Qualifiers="0"1035/EventID
Level4/Level
Task0/Task
Keywords0x80000000000000/Keywords
TimeCreated SystemTime="2017-08-20T01:40:45.579680500Z" /
EventRecordID1814502/EventRecordID
ChannelApplication/Channel
ComputerDad3/Computer
Security UserID="S-1-5-18" /
/System
EventData
DataMicrosoft .NET Framework 4.5.1 Multi-Targeting Pack/Data
Data4.5.50932/Data
Data1033/Data
Data0/Data
DataMicrosoft Corporation/Data
Data(NULL)/Data
Data
/Data
Binary
7B36413043363730302D454139332D333732432D383837312D 444343463133443136304134
7D303030306466326539303661656163353630643833303034 613662646535346464343634
3030303030393034/Binary
/EventData
/Event


https://support.symantec.com/en_US/a...ECH171048.html

"Known Issue.

The issue is reproducible.

When SIM is launched, It calls 'SetInstalledProducts' method
to find out the installed products to display in
Installed Products view on SIM.

Internally, this method is reading the property - 'PackageCode'
using windows unmanaged APIs

MsiOpenProduct,MsiGetProperty and MsiCloseHandle.

MsiCloseHandle method is causing the event

'Windows Installer reconfigured the product'
"

That means something is doing properties on all your MSI packages,
and isn't really doing anything to them. The act of closing
the handle to the MSI, is causing the generation of a nuisance
message (into the Event log).

If I pour that back into Google, I get:

https://support.microsoft.com/en-us/help/974524

"This problem can happen if one of the following is true:

* You have a group policy with a WMIFilter that queries Win32_Product class.

* You have an application installed on the machine that queries Win32_Product class.

Note For more information about WmiFilters please refer to:
KB555253 - HOWTO: Leverage Group Policies with WMI Filters
"

Which isn't particularly helpful. Dumping it back into Google,
indicates someone uses it, but not whether it's popular to do that.

https://sdmsoftware.com/group-policy...t-is-bad-news/

Another web page says this command would trigger it. In Admin Powershell...

get-wmiobject win32_product

My knowledge of WMI would fit in a thimble, so I'll stop there.
I don't know how to track it down. Is it a Windows subsystem making
those calls ? Probably not, because Microsoft already knows
of that side-effect. But a third-party might issue the call.

Paul

On Sat, 19 Aug 2017 23:29:53 -0400 "Paul" wrote in
article
My knowledge of WMI would fit in a thimble, so I'll stop there.
I don't know how to track it down. Is it a Windows subsystem making
those calls ? Probably not, because Microsoft already knows
of that side-effect. But a third-party might issue the call.


Hmm - I have made no changes to the system recently...at least that I know
of, but some apps update silently which may have triggered this (Adobe CC
is one). Coincidentally, Defender kicked off a scan that completed with
nothing suspicious to report. Thanks for looking.

On Sat, 19 Aug 2017 23:36:27 -0400 "Jason" wrote
in article

Hmm - I have made no changes to the system recently...

Well, that's not strictly true. I have tried several times recently to
upgrade to the latest Win build with no success. Perhaps something in that
process caused this. ?

"Paul" wrote

| "This problem can happen if one of the following is true:
|
| * You have a group policy with a WMIFilter that queries Win32_Product
class.
|
| * You have an application installed on the machine that queries
Win32_Product class.
|

That's probably common for programs that claim to
offer system info by doing things like listing installed
programs. It doesn't surprise me that Symantec
products might do that. They like to present their
software as being high-tech system software.

WMI's Win32_Product offers the following properties:

Caption
Description
IdentifyingNumber
InstallDate
InstallLocation
InstallState
Name
PackageCache
Vendor
Version

WMI is a system designed to make life easier for sys admins.
Among the many things it wraps is Windows Installer. The old
way to enumerate installed software was to enumerate the
key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Uninstall\. One can still use that method, but
WMI also wraps Windows Installer functionality to provide an
easy, systematic, object-oriented way to enumerate
installed software. But there's a catch: It only lists software
installed vis MSI, which is mainly only large-corporation
products used in business, so it has limited usefulness. Why
does that kind of software install via MSI? Because admins
want to be able to easily do things like enumerate installed
software across a network.

So it's not of much use to enumerate software via WMI, but
it is handy for sys admins to handle common corporate software
like MS Office, remotely.

For the most part you're missing nothing but a very
poorly designed and clunky wrapper object model by
not knowing about WMI. Most of what it can do can be
done better by more direct means. The one exception
is system info. Before WMI there was very little system info
available from Windows functions, other than things like
disk info, screen size, etc. With WMI, one can build a
snazzy loooking system info program in a few hours.

You might find this interesting.... Copy the following to
Notepad, save as a .vbs file, run it, and you'll get a
system info file created in C:\. It's made possible by
WMI. (This assumes WMI is running. It does by default,
but in general it's not really necessary.)

'-- begin script here -----------------------

Dim WMI, Col, Ob, S2, i2, s3, sFil, sBul, sLine

'-- path to save data. ------------------
sFil = "C:\Sysinfo.txt"

sBul = " " & Chr(149) & " "
sLine = vbCrLf & "_____________________________________________ " & vbCrLf &
vbCrLf

Err.Clear
On Error Resume Next

Set WMI = GetObject("WinMgmts:")

If (Err.number 0) Then
MsgBox "Error creating WMI object. Error: " & Err.Number & " - " &
Err.Description
WScript.quit
End If


'-------------- product ------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_ComputerSystemProduct")
S2 = S2 & sBul & " Product Info:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Product Name: " & Ob.Name & vbCrLf
S2 = S2 & "Product Version: " & Ob.Version & vbCrLf
S2 = S2 & "Product Description: " & Ob.Description & vbCrLf
S2 = S2 & "IdentifyingNumber: " & Ob.IdentifyingNumber & vbCrLf
S2 = S2 & "Product UUID: " & Ob.UUID & vbCrLf
Next
S2 = S2 & sLine


'-- box
id --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_SystemEnclosure")
S2 = S2 & sBul & "Machine ID (SystemEnclosure) info:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Part Number: " & Ob.PartNumber & vbCrLf
S2 = S2 & "Serial Number: " & Ob.SerialNumber & vbCrLf
S2 = S2 & "Asset Tag: " & Ob.SMBIOSAssetTag & vbCrLf
Next

S2 = S2 & sLine

'--
motherboard --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_MotherboardDevice")
S2 = S2 & sBul & "Motherboard info:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Caption: " & Ob.Caption & vbCrLf
S2 = S2 & "InstallDate: " & Ob.InstallDate & vbCrLf
S2 = S2 & "DeviceID: " & Ob.DeviceID & vbclrf
Next
S2 = S2 & vbCrLf

'----------- bios -----------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_BIOS")
S2 = S2 & sBul & "BIOS info:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Version: " & Ob.Version & vbCrLf
S2 = S2 & "InstallDate: " & Ob.InstallDate & vbCrLf
S2 = S2 & "SerialNumber: " & Ob.SerialNumber & vbCrLf

Next
S2 = S2 & sLine


'--
CPU --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_Processor")
S2 = S2 & sBul & "CPU:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Name: " & Ob.Name & vbCrLf
S2 = S2 & "Speed: " & Ob.MaxClockSpeed & sLine
Next

'-- RAM and product
info. --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_ComputerSystem")
S2 = S2 & sBul & "Installed RAM: "
For Each Ob in Col
i2 = Ob.TotalPhysicalMemory
If i2 0 Then
i2 = i2 \ 1024 \ 1024
S2 = S2 & CStr(i2) & " MB" & vbCrLf
End If
S2 = S2 & sLine
Next

S2 = S2 & sBul & "PC Info.:" & vbCrLf &vbCrLf

For Each Ob in Col
S2 = S2 & "PC or motherboard model: " & Ob.Model & vbCrLf
S2 = S2 & "System name: " & Ob.Name & vbCrLf
S2 = S2 & "System Manufacturer: " & Ob.Manufacturer & vbCrLf
Next
S2 = S2 & sLine

'---------- onboard devices ----------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_OnBoardDevice")
S2 = S2 & sBul & "Onboard devices:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Name: " & Ob.Name & vbCrLf
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf
S2 = S2 & "Model: " & Ob.Model & vbCrLf & vbCrLf
Next
S2 = S2 & sLine

'--
graphics --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_VideoController")
S2 = S2 & sBul & "Graphics:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Name: " & Ob.Name & vbCrLf
i2 = Ob.AdapterRAM
If i2 0 Then
i2 = i2 \ 1024 \ 1024
S2 = S2 & "RAM: " & " MB" & vbCrLf
End If
S2 = S2 & "Driver Date: " & Ob.DriverDate & vbCrLf
S2 = S2 & "Driver Version: " & Ob.DriverVersion & vbCrLf
Next
S2 = S2 & sLine

'-- hard
disks --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_DiskDrive")
S2 = S2 & sBul & "Drives:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf
S2 = S2 & "Model: " & Ob.Model & vbCrLf
S2 = S2 & "InterfaceType: " & Ob.InterfaceType & vbCrLf
S2 = S2 & "MediaType: " & Ob.MediaType & vbCrLf
S2 = S2 & "DeviceID: " & Ob.DeviceID & vbCrLf
S2 = S2 & "Number of Win Partitions: " & Ob.Partitions & vbCrLf
s3 = CStr(Ob.Size)
If Len(s3) 9 Then
s3 = Left(s3, (len(s3) - 9))
S2 = S2 & "Size (GB): " & s3
End If
S2 = S2 & vbCrLf & vbCrLf
Next
S2 = S2 & sLine

'-- CD/DVD
drives --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_CDROMDrive")
S2 = S2 & sBul & "CD/DVD drives:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Caption: " & Ob.Caption & vbCrLf
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf & vbCrLf
Next
S2 = S2 & sLine

'-- network
adapter --------------------------------------------------------------------

Set Col = WMI.ExecQuery("Select * from Win32_NetworkAdapter")
S2 = S2 & sBul & "Network Adapter:" & vbCrLf & vbCrLf
For Each Ob in Col
S2 = S2 & "Description: " & Ob.Description & vbCrLf
S2 = S2 & "Name: " & Ob.ProductName & vbCrLf
S2 = S2 & "Manufacturer: " & Ob.Manufacturer & vbCrLf
S2 = S2 & "MAC Address: " & Ob.MACAddress & vbCrLf & vbCrLf
Next
S2 = S2 & sLine

Set Col = Nothing
Set WMI = Nothing

Dim FSO, TS
Set FSO = CreateObject("Scripting.FileSystemObject")
Set TS = FSO.CreateTextFile(sFil, True)
TS.Write S2
TS.Close
Set TS = Nothing
Set FSO = Nothing
MsgBox "Done."

"Mayayana" wrote

.....

PS - Watch out for word wrap if you try that code.
Newsreaders will break long lines, but in VBS a
line return is the end-of-line marker.

Jason wrote:
On Sat, 19 Aug 2017 23:36:27 -0400 "Jason" wrote
in article

Hmm - I have made no changes to the system recently...

Well, that's not strictly true. I have tried several times recently to
upgrade to the latest Win build with no success. Perhaps something in that
process caused this. ?

There is an Upgrade Advisor phase, where the installer looks
at the system. For example, later in the install, there is
"Migration Logic", and the things it moves, you would not want
them to be items on any black list.

When my Insider edition upgrades, certain things always receive
poor treatment. My RAMdisk software gets damaged. I have to
go to Programs and Features after the OS is upgraded to the
next version, and do a "Repair" and after that, the RAMdisk software
works again (the control panel will actually start for it).

The installer has an incentive to go through your installed
programs. On previous OSes, there used to be an interface,
where, before the install started, it would list things
that you needed to fix. In Win10, this is largely invisible.
Except if it decides to block for some reason.

Somewhere in all those log files, there will be a reason why
it might be blocking. But don't expect it to be started in
plain English.

Another thing that could happen, is the install could actually
start, encounter a fatal error, then roll back to the previous
Windows folder. And the log would likely be a lot larger.

The log ends up in two places. The install involves multiple
boot cycles. The step before the first reboot (copying files),
you'll probably find a log in C:\$Windows.~BT. Once the thing
reboots and the install actually kicks off, the subsequent logging
goes into a different file. There is a new C:\Windows and your
old C:\Windows.old. The Windows.old might be 20GB in size.

A different install method can be used on 32GB eMMC "tablets" or
similar. They don't have enough storage, and may require an SD
card or a USB flash drive for "scratch" storage.

The hiberfile and pagefile can be sub-sized, if there isn't
enough room for an install. The Win10 installer is one of the
most "accommodating" installers Microsoft has ever written.
and I take my hat off to them, for "bailing less often"
under adversity. I've purposefully used a too-small C:
drive, just to see if they can handle it.

For a Windows Update inspired OS Upgrade, gathering drivers
is one of the early steps (a DVD install doesn't do it that way).
A little thing, like an inability to stage a display driver,
can be enough to block the WU-inspired install.

Microsoft doesn't feel under any pressure yet. You may find
your Upgrade takes off a bit before November, in anticipation
of the next version.

I've always rammed my Release upgrades in from a DVD, and
I don't wait for WU to do it. I do a backup, take a bash at
it, see what happens. If anything negative were to happen,
then it's "restore from backup" time. One of the reasons I
can do that, is I don't own a tablet, or an item with an
eMMC in it, or an item fixated on Secure Boot, and for the
most part, my systems are maintainable. A disk backup is
enough in my case. I wouldn't be brave enough to force
an Upgrade into a tablet, unless the tablet was "free" or
something :-) If I paid good money for it, I'd let WU do it.

Paul

[This followup was posted to alt.comp.os.windows-10 and a copy was sent
to the cited author.]

In article , am says...
You might find this interesting....


I did! Thank you.

On Mon, 21 Aug 2017 00:06:10 -0400 "Paul" wrote in
article
A little thing, like an inability to stage a display driver,
can be enough to block the WU-inspired install.

My latest install failures were with a DVD I burned instead of waiting 20
minutes each time for the download. Even with the ISO image, there's a
step where Checking for Updates and then Getting Things Ready take a long
time. Perhaps that's where it's hunting for updated drivers? Once, during
a failed install, a message popped up about a connection being blocked by
my firewall on behalf of a process with a long hexadecimal identifier. I
figured that might be the failure cause and tried again with all that
stuff disabled. Didn't get the message, but installation failed anyway...

Jason wrote:
On Mon, 21 Aug 2017 00:06:10 -0400 "Paul" wrote in
article
A little thing, like an inability to stage a display driver,
can be enough to block the WU-inspired install.

My latest install failures were with a DVD I burned instead of waiting 20
minutes each time for the download. Even with the ISO image, there's a
step where Checking for Updates and then Getting Things Ready take a long
time. Perhaps that's where it's hunting for updated drivers? Once, during
a failed install, a message popped up about a connection being blocked by
my firewall on behalf of a process with a long hexadecimal identifier. I
figured that might be the failure cause and tried again with all that
stuff disabled. Didn't get the message, but installation failed anyway...

Look at your Windows Update history, and make sure there are no
"Failed" updates, which lack a "Success" entry later on. Anything
which is "Failed" and didn't get tried again, could screw up the
WU state.

You can download individual KB items from catalog.update.microsoft.com
and install them. Each downloaded MSU file, knows whether the file is
"appropriate" for the situation. And the success of that method, is
usually better than WU itself.

The OS might want to do a Windows Defender definition update. I
managed to find a download link one day, to be able to do that
"offline". And managed to run the file, before the normal updates
processes started on reboot.

There could also be a pending MRT/MSRT scanner for the month, which
is outstanding. I seem to run into that a lot, and it requires
to run before the OS Upgrade will begin. Chances are that comes
out on Patch Tuesday (Aug.8).

You *can* resolve some of its more pesky "Searching for Updates"
things. Since Windows Defender is updated a few times a day,
it's pretty hard to satisfy it and kick of the upgrade without
it trying to run again.

Paul