Intel Graphics Driver `n2hdr35w` install hanging

[wgriffinArch]

Version

1.5.1

Computer Model

20QD000LUS

Problem

I was using v1.5.1 The model that ran for 2 hours is a 20QD000LUS.

I started a transcription at the beginning of the script and here is a portion....

VERBOSE: Installing package n2hdr35w ... WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:05:00.0631418 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:06:00.2160740 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:07:00.3573137 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:08:00.5349774 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:09:00.5879147 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:10:00.6869739 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:11:00.7201102 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:12:00.8793736 WARNING: Process 'C:\WINDOWS\TEMP\LSUPackages\n2hdr35w\installer.exe' has been running for 00:13:01.0690935

it just kept going til i came back, and killed the script.

Additional context

No response

[jantari]

Since n2hdr35w is an Intel Graphics Driver package I think you might be running into #49?

If you are running LSUClient as the SYSTEM user you should try running the installer from a different directory like:

$updates = Get-LSUpdate
$updates | Save-LSUpdate -Path "something\not\inside\c\windows" 
$updates | Install-LSUpdate -Path "something\not\inside\c\windows" 

[wgriffinArch]

I had no idea. Sounds like my issue. We are also using a management tool to invoke the powershell as the SYSTEM account. To fix this permanently could it be made to detect it's running as SYSTEM and use a different path? Rather than have us remember to change the path.

None the less: if ((whoami) -eq 'nt authority\system') { if !(Test-Path 'C:\temp\LSUtemp'){md 'C:\temp\LSUtemp'} $updates = Get-LSUpdate $updates | Save-LSUpdate -Path "'C:\temp\LSUtemp'" $updates | Install-LSUpdate -Path "'C:\temp\LSUtemp'" }

[wgriffinArch]

So ran this code if ((whoami) -eq 'nt authority\system') { if (!(Test-Path 'C:\temp\LSUtemp')) {md 'C:\temp\LSUtemp'} $updates = Get-LSUpdate -Verbose $updates | Save-LSUpdate -Path 'C:\temp\LSUtemp' -Verbose $updates | Install-LSUpdate -Path 'C:\temp\LSUtemp' -Verbose }

And left it to go for 58 mins. I finally stopped it. I redid the last line with -Debug.

`PS C:> $updates | Install-LSUpdate -Path 'C:\temp\LSUtemp' -Debug
DEBUG: Starting external process: File: C:\temp\LSUtemp\n2hdr35w\n2hdr35w.exe Arguments: /VERYSILENT /DIR=C:\temp\LSUtemp\n2hdr35w\ /EXTRACT="YES" WorkingDirectory: C:\temp\LSUtemp\n2hdr35w DEBUG: Added runspace process 23700 to job: True DEBUG: Starting external process: File: C:\temp\LSUtemp\n2hdr35w\installer.exe Arguments: -s WorkingDirectory: C:\temp\LSUtemp\n2hdr35w DEBUG: Added runspace process 30628 to job: True WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:05:00.1873059

WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:06:00.3904396

WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:07:00.5212628

WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:08:00.5433472

WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:09:00.7275318

WARNING: Process 'C:\temp\LSUtemp\n2hdr35w\installer.exe' has been running for 00:10:00.9187083`

Stopping it after 10 mins. Finally tried it again but with a Domain Admin account instead of SYSTEM. And the user told me he got a popup at the end saying he needed a reboot. He said dismissed the window and it finished the install in under 3 mins. It was supposed to be /verysilent.

[jantari]

I'm surprised it's not (just) the same cause as #49.

With LSUClient 1.5.3 I have added additional debug information about long-running (potentially stuck) processes like yours here, so if you could reproduce this problem again with LSUClient version 1.5.3 and with -Verbose -Debug options enabled and send the complete output log I hope it will help understand the cause.

[Ravagon]

I have the same issue but I believe it is the newer Lenovo driver packs popping up a Dialog window asking for confirmation to install firmware/bios. It doesn't show up when running Powershell so the script just sits and waits until you kill it. My suggestion is to add Powershell -Confirm:$false flag to give the package confirmation yes to continue the installation.

[wgriffinArch]

maybe add that switch to each one that claims to be silent but really isn't if it fixes these.

[jantari]

Any packages that open up dialog windows and require some interaction to start installing should be marked as .Installer.Unattended = $false. If that's not the case and you find one that's supposedly unattended but isn't then please open an issue with the specific computer model and package ID - like this one here.

If there are any dialog windows though they will show just the same when run from PowerShell, at least when you run it locally as a logged in user where a GUI is available. Different remoting software may not always be configured to allow local desktop interaction, so in a case like this it'd be best to test it in a graphical session.

[jantari]

@wgriffinArch Have you been able to reproduce this issue on 1.5.3 and captured the logs?

[SenderLen]

I have a similar issues with "n2tdr66w : Intel Graphics Driver - 10 (1709 or later)/11 (21H2 or later)" Installer.Unattended is True in my case.

installer.exe needs to be terminated, looks like it is starting user interactive wizard.

ThinkPad X1 Carbon Gen 9 Type: 20XX

I'm using 1.5.3

[jantari]

@SenderLen did you make sure you're not trying to install from C:\Windows\Temp (https://github.com/jantari/LSUClient/issues/49)?

And please capture logs with -Verbose -Debug on all cmdlets to diagnose the issue.

[SenderLen]

@jantari Thank you, that was the exact reason!

This was fixed by using another path.

$updates = Get-LSUpdate
$updates | Save-LSUpdate -Path c:\temp
$updates |Install-LSUpdate -Path c:\temp 

[Herc08]

Thanks for this. I also received this error on a 7th Gen X1 Carbon. Tested this module o na 6th gen and T15 2nd Gen, along with a T14 3rd gen.

I typically run the script at the end of OSD in MECM. So not sure why it failed now. My error showed this

`WARNING: Process 'C:\WINDOWS\TEMP\LSU\n2hdr35w\installer.exe' has been running for 00:05:00.2442556
WARNING: 4172: 'Installer' started at 18:19:37.5422189
WARNING: Process has windows open, this can help troubleshoot if it is stuck: WARNING: - Title: ------------------------------------------- WARNING: HandledStartupErrorWindow
WARNING: - Content: ----------------------------------------- WARNING: Graphics Driver Installer
WARNING:
WARNING:
WARNING:
WARNING: The application cannot be launched.
WARNING: The application is in an unauthorized location. Please move to a non-system folder.
WARNING: OK
WARNING: ----------------------------------------------------

This is weird because I'm pretty sure I installed that driver multiple times on other devices. Could have been just this device, or something.

Nevertheless, this gave me an opportunity to update to 1.5.5 and add a few lines of code $LSUDownloads = 'C:\Temp\LSU' if (-not(Test-Path $LSUDownloads)) { New-Item -Name Temp -Path C:\ -ItemType Directory New-Item -Name LSU -Path C:\Temp -ItemType Directory }

[jantari]

It can vary depending on which user account you use to run LSUClient, since the default download and run location for packages is inside $env:TEMP:

https://github.com/jantari/LSUClient/blob/a68c85fbd721e00576d1f32abd9bdafbdeb31e70/public/Install-LSUpdate.ps1#LL39

and $env:TEMP points to a per-user location, or to C:\Windows\TEMP if you're running as SYSTEM.

[jantari]

@wgriffinArch has the problem been solved for you as well?

[jantari]

Closing because it's likely fixed and no response