Intel System Usage Report (SUR) update initiated a system restart without user consent

[rcp]

Please ensure that future versions of this package do not automatically restart the computer without user consent.

Events:

Log: Application
Source: MsiInstaller
Timestamp: 21/09/2021 15:01:02
User: SYSTEM

EventID: 1042

Description: Ending a Windows Installer transaction: C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Intel\SUR\QUEENCREEK\Updater\AppData\downloads\86621605-2a0b-4128-8ffc-15514c247132\IntelSURQCSoftwareAssetManagerInstaller.msi. Client Process Id: 3812.

EventID: 1033

Description: Windows Installer installed the product. Product Name: Intel(R) SUR QC Software Asset Manager. Product Version: 3.5.5033. Product Language: 0. Manufacturer: Intel Corporation. Installation success or error status: 0.

EventID: 1005

Description: The Windows Installer initiated a system restart to complete or continue the configuration of 'Intel(R) SUR QC Software Asset Manager'.

[allklier]

I think most of us ended up doing that already.

That said, I think it would still be advisable to fix that error. Because right now everyone who opted into that installation will only find out about having to uninstall it after at least one painful reboot. So I'd much rather see Intel owning this and patching the tool.

Jan

[SquidNET]

Is that it?
Hmm, I'm sorry @Ronny_G_Intel and @David_G_Intel , but this really is not much of an answer and certainly isn't a 'solution'.  It's a technical 'fix' at best, a work-around, a bodge - and only for a select few who here.  Not to mention that the 'removal' of an offending item does not resolve whatever it is that makes the item an offensive one!

The solution is for Intel to actually take ownership of the problem and fix their software, thereby showing some humility, common decency and empathy to their loyal customers!

Let's look at this supposed 'solution' in a different context and see how it would play out and look...

Say you go shopping one day and buy a can of beans.  That evening you eat them for dinner.  That night you're really sick and get no sleep at all.
In the morning you look at the foods you consumed the previous day.  All but one of them are things you consume every single day.  The only item that was a new addition was the beans.  So you investigate them.  Eventually you find that at the bottom of the tin there was some weird gloop.  On closer inspection you find that it's got a weird smell and seems to be some kind of mold.  So the mold/gloop had to be responsible.

You start to hear on the grapevine that others that bought those beans have had the exact same experience.

You and others report it to the manufacturer.  Three and a half weeks later and after many many others report the same, the manufacturer responds.  They tell you, and others, in future to:

1. Get a good tin opener and a bowl
2. Use the tin opener to open the can of beans
3. Empty into a bowl and examine the contents and the bottom of the tin to see if there is mold present
4. If so, throw the mold and beans into the bin, and if you still have the tin, dispose of that too.

Or, they say, you can simply return the can of beans without opening it.

Problem solved and apparently accepted.

Really?!  No, it's not.  And that it effectively what you have proposed here.

What you/Intel actually need to be telling us is why the issue happened in the first place (that will undoubtedly require an admission of fault), how deeply and genuinely sorry you/Intel are that your loyal customers have individually lost tens or more hours of hard work, time, money and reputation in the eyes of their clients, and then, critically, what you/Intel are going to do to resolve the issue (i.e. fix your tool and re-issue/update urgently)

Your current 'solution' does none of that, nor does it in any way prevent all the other unsuspecting victims from experiencing this disgraceful failure in technical professionalism in the coming hours, days, and weeks until it is too late.

We here are all extremely lucky to the extent that we have managed to find our way to the cause and a 'fix' that we can employ - but most users will not have the knowledge to have got so far.  These people, your customers, through no fault of their own are left in an even more desparate mess as a result - and one that could re-occur again... and again... and again.

Can you not see what a travesty and utter display of contempt towards your customers that is?  It's beyond disgusting.

I'm sorry for the strong wording, but really, try a bit of empathy rather than apathy - what if this happend to you, or a loved one who was absolutley distraught after losing hours and hours of their work, all because a company that was aware their software could cause this, felt no need to actually do anything about it???

[RTPGiants]

To continue to add on here. Intel seems to be user blaming with "you opted into this". While technically this may be true, at least in my case the Intel software was a preload from Lenovo. It's possible I clicked through an accept somewhere, but I seriously doubt the opt in included a "may reboot without user warning". I try (and I encourage my employees) to try to stay up to date on security and driver updates including what Intel provides. The possibility of one of Intel's improvement programs costing work and creating a potential security panic ("why did my computer suddenly reboot???") is unacceptable.

This needs to be addressed with an actual fix, not just a "don't use our software" response.

[rcp]

@Ronny_G_Intel and @David_G_Intel ,

The solution that seems reasonable for this case must first avoid new occurrences, without depending on the execution of any procedures by the consumers.

It would be nice to leave a definitive answer here. This case is more serious than one might estimate.

For instance:

[if the installation parameters are delivered together with the MSI package]

• 1st step) Publish a new version of the package metadata with this additional parameter: REBOOT=ReallySuppress
• 2nd step) Let consumers know that the issue has been solved, confirm that it won't happen again, and finally apologize.
  
  

[if the installation parameters are hard-coded in the update module]

• 1st step) Publish a new MSI database with this property hard-coded: REBOOT=ReallySuppress
• 2nd step) Change the update module so that it always calls MSI packages with this parameter: REBOOT=ReallySuppress
• 3rd step) Let consumers know that the issue has been solved, confirm that it won't happen again, and finally apologize.

[allklier]

To add to what was already said - re-reading what @Ronny_G_Intel wrote, it made it sound like 

a) It's an optional install

b) During the optional install the installer ends up rebooting the system to complete the install

That wouldn't be so bad. Most new installs do that. They do give you a heads-up, but most people expect to reboot during half the installs they do.

What is different about this case, is that this appears to be a scheduled upgrade that happens in the background without the user being aware of it, or having asked for it. And boom, suddenly your system reboots. In some cases months after you originally agreed to add the SUR software. So it happens out of the blue when the user is potentially doing critical work tasks.

That's what makes this case so egregious and I do agree, there seems to be a level of dismissiveness here that not helping at all.

It's one thing to reboot upon an attended user install, it's another thing to reboot without warning at random times.

So time to fix this properly.

Jan

[ComeOnNow]

I'm not one to pile on, but I feel like this situation demands it.

I've been a software developer for 20 years. Before that I worked in IT roles. I have never in all of that time encountered a silent update that rebooted the computer without any notice. 

When this happened to me, my first instinct was not, "oh some software must have updated", instead I thought my machine was somehow compromised. Only a malicious actor would reboot the computer. I pulled the network cable.

And then you factor in the lost work, most of the responders here probably use a Uninterrupted Power Supply to avoid power outages. It's very important to us to not lose work, and you bypassed all precautions.

The bigger story is quickly becoming rather than admitting and explaining a mistake was made, that a developer incorrectly set a restart flag, and the steps you are taking to avoid this from happening in the future, you are just telling us to uninstall the software. Seriously?

You are so lucky that so few users will figure out how to determine the cause of the random reboots that are happening throughout the world. Perhaps your legal team understands the full risk of randomly rebooting critical machines and is preparing for the lawsuits when some loses more than just their work and time. Maybe they have instructed you to avoid ownership. At least have one of your lawyers show up and give us a PR answer rather than insulting us with uninstall directions.

[Monique_Intel · Accepted solution]

@rcp @ComeOnNow @RTPGiants  @SpragueR @Salim @Emil1 @PartTimeGeek @SquidNET @allklier @mjflorida 

As the Intel Project Manager for IDSA, I work closely with the ICIP team, and this thread was escalated to me. Thanks to the details in this thread and the comments provided, the ICIP team identified the root cause of the issue and found it was due to a recent server side change made on September 13 that triggered the Intel SUR QC Software Asset Manager to self-upgrade on machines with ICIP installed.

The ICIP team took down the SAM MSI package so the Intel SUR QC Software Asset Manager client will not trigger a self upgrade as it won’t find a newer version from the backend. This will prevent triggering any self-upgrade so users with ICIP still on their systems will no longer experience this sudden reboot.

We appreciate everyone who notified us of this issue. It certainly was not our intent to cause the systems to reboot.

Monique with Intel Corporation

[rcp]

@Monique_Intel,

I appreciate the feedback.

It's good to know that the root cause has been identified and the issue fixed.

[Thaís]

Hi everyone, I'm having the same issue and I can't solved.

Who can help me??

Greetings,

Thaís

[Thaís]

Sorry I forgot to add the image.

Thaís

[Monique_Intel]

Hello @Thaís  I'm the Intel Project Manager for IDSA and I work closely with the Intel® Computing Improvement Program team.  We believe you have an older version of ICIP installed, so this issue should be resolved if you upgrade to the latest version. You can find the download posted to our Intel site here: https://www.intel.com/content/www/us/en/support/topics/idsa-cip.html

Monique with Intel Corporation

[Monique_Intel]

Monique with Intel Corporation

[Thaís]

Hi Monique, thanks for the response, but the problem continue.

I'm playing in STEAM platform, any game and the PC shutting down.

I did the upgrade that you recommended and nothing.

I appreciate your help,

Thaís

[Monique_Intel]

@Thaís  I'm sorry to hear that didn't work. Can you check which version of the Intel Computing Improvement Program you now have? It should be 2.4.10717

Monique with Intel Corporation

[Thaís]

Its the same.

[Monique_Intel]

@Thaís  Thanks for confirming. We recommend that you uninstall ICIP following the instructions listed at Leaving the Program “How do I uninstall the Intel® Computing Improvement Program?” under the FAQ page.

Hopefully that will resolve this. Please be sure to reboot after uninstalling.

Monique with Intel Corporation