4

To overcome an annoying bug in Windows 10, I found a solution. The problem is, it's a lot of clicking and I'd like to automate the steps (script?) if possible. Here's the context from Reddit:

There is an easier fix though than restarting, if you go to Device Manager, then under Sound, Video and Game controllers, find: Intel Display Audio and disable then re-enable and it should fix it.

There is an answer showing how to do this at the command-line with a third-party tool (devcon). But I'm not happy to install/maintain it and not even sure if it works in Windows 10. I'd like to be able to do this without any third-party tools.

It doesn't have to be a command-line script. I'd just like to be able to do this in a single gesture (double-click of a desktop icon is fine, maybe a Cortana command can do it?).

4
  • I was not able to find a solution without Devcon or a PowerShell module to download. Here is an article explaining how to disable a device with PowerShell, using a simple module to import : blog.kulman.sk/…
    – Ob1lan
    Jan 11, 2017 at 8:49
  • 2
    Hey, on Windows 10 I found something that might interrest you : Get-PnpDevice. Try to use this command to get the FriendlyName of your sound device, then try something like this : Get-PnpDevice -FriendlyName "My USB Audio Device" | Disable-PnpDevice -confirm:$false
    – Ob1lan
    Jan 11, 2017 at 11:51
  • 1
    @Ob1lan It works on my system, with Get-PnpDevice -FriendlyName "Intel(R) Display Audio" | Disable-PnpDevice -confirm:$false; Get-PnpDevice -FriendlyName "Intel(R) Display Audio" | Enable-PnpDevice -confirm:$false -- I put this in a .ps1 file, then a shortcut per stackoverflow.com/a/10137272/1168342 - I didn't quite figure out how make it run always as requesting admin, but right-clicking the shortcut allows that option. Not quite one gesture, but it probably can be done. Thanks! Jan 11, 2017 at 19:53
  • Posted the answer with the solution for the Run as admin. Hope this helps !
    – Ob1lan
    Jan 12, 2017 at 7:45

3 Answers 3

4

Based on my research and as the command works for you (as per your comment), here is the final script that may work as 'one gesture'. I've added at the begining some instruction to run as admin automatically (self elevated). This will only works if the user is admin of the computer, of course.

The final script, you may save as '.ps1' file, and execute with PowerShell :

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)

# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator

# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
    $Host.UI.RawUI.BackgroundColor = "DarkBlue"
    clear-host
}
else
{
    # We are not running "as Administrator" - so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter
    $newProcess.Arguments = $myInvocation.MyCommand.Definition;

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    exit
}
Get-PnpDevice -FriendlyName "Intel(R) Display Audio" | Disable-PnpDevice -confirm:$false
Get-PnpDevice -FriendlyName "Intel(R) Display Audio" | Enable-PnpDevice -confirm:$false
2
  • 1
    This works, but I'm not sure what all the if/else code adds. When I tried this, I still get a pop-up to elevate permissions (thus it's two gestures, just as my answer that I just added). In Windows 10, I can tick "Run as administrator" on the Shortcut's advanced options to accomplish the same as all that code (I think). Am I missing something in your solution? What is strange to me is that no elevation is required if I do these things by clicking in the device manager. Jan 12, 2017 at 19:05
  • I am also puzzled why it does not seem to be possible to execute those fantastically simple PS commands without elevated rights...
    – Christoph
    Oct 10, 2018 at 14:20
3

This simple solution worked for me.

  • Create a windows shortcut with this Target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Get-PnpDevice -FriendlyName \"Intel(R) Display Audio\" | Disable-PnpDevice -confirm:$false; Get-PnpDevice -FriendlyName \"Intel(R) Display Audio\" | Enable-PnpDevice -confirm:$false"
  • In the Shortcut's Properties > Shortcut > Advanced properties, tick "Run as administrator" enter image description here

It's finally TWO gestures, since you have to permit the permission elevation. When I tried @Ob1lan's answer, I also had to click to allow elevation (the second gesture). So, this is not an ideal answer according to the original question. Note: Manual disabling/enabling the device (as described in the question) doesn't require elevation.

The reason I avoided the script file (.ps1) is it requires an additional set of workarounds because of security, and even though there's a lot of checking for administrator, it doesn't add value over ticking the shortcut "Run as administrator" option. See https://stackoverflow.com/questions/4037939/powershell-says-execution-of-scripts-is-disabled-on-this-system for more info.

1
  • Nice solution, is it possible to use a statement to toggle the on/off state of the device, or do I have to use two shortcuts for that?
    – Albin
    Apr 25, 2019 at 3:28
0

I have had some trouble getting @Ob1lan's script to work out of the box because in order for it to work (i.e. to allow a script to elevate itself), the Powershell Execution Policy has to allow that. One way to do it is to set it globally using Set-ExecutionPolicy. My preference is, though, to leave the global policy untouched and bypass it whenever needed using the -ExecutionPolicy ByPass argument.

So below is the slightly modified script as I am using it now to disable my touch screen. Apart from adding the bypass, I also added the -WindowStyle hidden argument to prevent too many windows polluting my screen. (Hint: if the script doesn't work as desired, I recommend you first replace that argument with the -noexit argument to see any error messages.)

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)

# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator

# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + " (Elevated)"
    $Host.UI.RawUI.BackgroundColor = "DarkBlue"
    clear-host
}
else
{
    # We are not running "as Administrator" - so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter, hide window and bypass execution policy (in case it has not been disabled globally)
    $newProcess.Arguments = '-ExecutionPolicy ByPass -WindowStyle hidden ' + $myInvocation.MyCommand.Definition + '" ';
    # Here are the changes   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    exit
}

 Get-PnpDevice | Where-Object {$_.FriendlyName -like '*touch screen*'} | Enable-PnpDevice -Confirm:$false

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .