none
Incorrect format problem with taskscheduled Scripts on Windows 10 build 1703

    Question

  • Hello,

    Since the upgrade to build 1703 we have some issues with scripts running at logon. I would like to describe one situation here and see if anyone can put in some insights so i can give it a new go next week, for now i will post this and let the problem here stew for a few days :)

    Regarding the script, it is a powershell script designed to run after a user logs into a Windows 10 desktop. The script gets called through a exe file which checks for ps1 scripts in a network location. The exe file runs after logon of the user (set as a scheduled task) under the SYSTEM account, the exe then enumerates ps1 script in a network location and runs the script under a local administror user.

    The ps1 script in question is basically only doing a "Get-WindowsOptionalFeature -Online" call for testing purposes at the moment. See below for full test script:

    #script voor installatie van .net framework 2.0
    
    #script elevaten naar administrator (wanneer niet het geval)
    if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }
    
    #logfile
    $logFile="D:\deRolfGroep\Logs\installDotNet.log"
    if ( Test-Path $logFile) {
            Remove-Item $logFile
    }
    
    Add-Content $logFile -value "start of installDotNet log"
    
    Add-Content $logFile -value "Get windows optional features"
    $test51=""
    try {
            $test51=Get-WindowsOptionalFeature -Online
    } catch {
            Add-Content $logFile -value "Error: $error"
            exit 1
    }
    Add-Content $logFile -value "Output: $test51"

    If i run this script manually from a powershell window, it will output the optionalfeatures to the log file on D: as expected.

    However, if i run it from the exe file, it will get into the catch section and output the following error to the logfile:

    "An attempt was made to load a program with an incorrect format", which would imply that the cmdlet is expecting to be run either under powershell 32 of 64bit and at that moment its being run under the wrong one.

    I have attempted to run the script under both 32bit (C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe) and 64bit powershell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe), but both attempts resulted in the same output. Also i have set the scheduled task to a normal user instead of SYSTEM, but that also produced the same results.

    Can anyone give me some insight into what is going wrong here? Am i correct to assume the problem lies with starting it from task scheduler and should i try to run it in another way?
    Friday, April 21, 2017 12:19 PM

Answers

  • The script gets called through a exe file which checks for ps1 scripts in a network location.

    We can't troubleshoot this part for you. If the script works when you run it from a PowerShell prompt, you don't have a scripting problem (and hence you're asking in the wrong place).


    -- Bill Stewart [Bill_Stewart]

    • Marked as answer by Jos Monnikhof Friday, April 21, 2017 12:35 PM
    Friday, April 21, 2017 12:32 PM
    Moderator
  • Yes i have noticed, in the end it was not the powershell script itself, but the exe that calls it.

    The exe was compiled for 32bit and apparantly did not have access to the 64bit powershell even though it could call it (apparantly windows proceeds with the request, but feeds it into the 32 bit powershell anyway). After recompiling to 64bit and testing again, the powershell script worked as expected.

    • Marked as answer by Jos Monnikhof Friday, April 21, 2017 12:35 PM
    Friday, April 21, 2017 12:35 PM

All replies

  • The script gets called through a exe file which checks for ps1 scripts in a network location.

    We can't troubleshoot this part for you. If the script works when you run it from a PowerShell prompt, you don't have a scripting problem (and hence you're asking in the wrong place).


    -- Bill Stewart [Bill_Stewart]

    • Marked as answer by Jos Monnikhof Friday, April 21, 2017 12:35 PM
    Friday, April 21, 2017 12:32 PM
    Moderator
  • Yes i have noticed, in the end it was not the powershell script itself, but the exe that calls it.

    The exe was compiled for 32bit and apparantly did not have access to the 64bit powershell even though it could call it (apparantly windows proceeds with the request, but feeds it into the 32 bit powershell anyway). After recompiling to 64bit and testing again, the powershell script worked as expected.

    • Marked as answer by Jos Monnikhof Friday, April 21, 2017 12:35 PM
    Friday, April 21, 2017 12:35 PM