win_update failed since ansible 7.7.0

[Xer69]

SUMMARY

Hello,

When I launch the module ansible_windows_win_update in ansible 6.7.0, it works.
I upgrade to the latest ansible version -> it failed. I follow the white rabbit and find it didn't work since ansible 7.7.0
Exception calling "NativeCreateProcess" with "9" argument(s): "CreateProcessW() failed (Access is denied, Win32ErrorCode 5 - 0x00000005)
maybe somthing to do with this commit : 16d2359

ISSUE TYPE

• Bug Report

COMPONENT NAME

win_update

ANSIBLE VERSION

ansible [core 2.14.14]
  config file = /home/xer/ansible-evt12-3cg/ansible.cfg
  configured module search path = ['/home/xer/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/xer/.local/lib/python3.9/site-packages/ansible
  ansible collection location = /home/xer/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/xer/.local/bin/ansible
  python version = 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] (/usr/bin/python3)
  jinja version = 3.0.3
  libyaml = True

also test with :

Python : 3.11.8
ansible : 8.7.0

COLLECTION VERSION

# /home/xer/.ansible/collections/ansible_collections
Collection      Version
--------------- -------
ansible.windows 2.3.0  

# /home/xer/.local/lib/python3.9/site-packages/ansible_collections
Collection      Version
--------------- -------
ansible.windows 2.3.0  

CONFIGURATION

ANSIBLE_PIPELINING(/home/xer/ansible/ansible.cfg) = True
CACHE_PLUGIN(/home/xer/ansible/ansible.cfg) = jsonfile
CACHE_PLUGIN_CONNECTION(/home/xer/ansible/ansible.cfg) = ./.cache
CACHE_PLUGIN_TIMEOUT(/home/xer/ansible/ansible.cfg) = 604800
CALLBACKS_ENABLED(/home/xer/ansible/ansible.cfg) = ['profile_tasks']
CONFIG_FILE() = /home/xer/ansible/ansible.cfg
DEFAULT_FORKS(/home/xer/ansible/ansible.cfg) = 50
DEFAULT_GATHERING(/home/xer/ansible/ansible.cfg) = smart
DEFAULT_LOG_PATH(/home/xer/ansible/ansible.cfg) = /var/log/ansible.log
DEFAULT_ROLES_PATH(/home/xer/ansible/ansible.cfg) = ['/home/xer/ansible/roles']
DEFAULT_STDOUT_CALLBACK(/home/xer/ansible/ansible.cfg) = yaml
HOST_KEY_CHECKING(/home/xer/ansible/ansible.cfg) = False

OS / ENVIRONMENT

ansible controller :
WSL2
cat /etc/debian_version
11.9

Target : Windows 2016 ssh with domain account

STEPS TO REPRODUCE

ansible my_host -i inventory -m ansible.windows.win_updates -C

EXPECTED RESULTS

MYHOST | CHANGED => {
    "changed": true,
    "failed_update_count": 0,
    "filtered_updates": [],
    "found_update_count": 2,
    "installed_update_count": 0,
    "reboot_required": false,
    "updates": [
        {
           ...
        },
        ...
    }
    ]
}

ACTUAL RESULTS

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible_collections.ansible.windows.plugins.action.win_updates._ReturnResultException: Failed to invoke batch job: Exception calling "NativeCreateProcess" with "9" argument(s): "CreateProcessW() failed (Access is denied, Win32ErrorCode 5 - 0x00000005)"
MYHOST | FAILED! => {
    "changed": false,
    "failed_update_count": 0,
    "filtered_updates": {},
    "found_update_count": 0,
    "installed_update_count": 0,
    "msg": "Failed to invoke batch job: Exception calling \"NativeCreateProcess\" with \"9\" argument(s): \"CreateProcessW() failed (Access is denied, Win32ErrorCode 5 - 0x00000005)\"",
    "updates": {}

Thank you for your help, I didn't see anything in windows logs event :(

[jborean93]

This is essentially a duplicate of #540. For whatever reason there is some sort of host configuration that I am unable to determine that causes win_updates to fail using the winrm connection plugin. As I am unable to replicate this scenario on any of my test hosts or in CI there is bound to either be some OS configuration that is causing the problem or potentially GPO or AV software causing the failure.

It is also possible to replicate this problem outside of Ansible and this module directly. It's been a while since I last had someone test it but IIRC the following failed when run from Windows

# Replace target-host with the affected Windows host you can WinRM to

Invoke-Command -ComputerName target-host -Command {
    (Start-Process cmd.exe -ArgumentList '/c exit 1' -UseNewEnvironment -Wait -PassThru).ExitCode
}

winrs -r:http://target-host:5985/wsman powershell.exe -Command "(Start-Process cmd.exe -ArgumentList '/c exit 1' -UseNewEnvironment -Wait -PassThru).ExitCode"

The first example replicates how the psrp connection plugin works in Ansible by using PSRemoting over WinRM to run a command. This should work and return an rc of 1. The second example uses winrs to spawn a process over WinRS/WinRM that replicates how the winrm connection plugin works in Ansible. This is the problematic one where for whatever reason the environment setup on the affected host doesn't allow you to create a new process with the CREATE_NEW_CONSOLE flag which is perfectly valid.

The actual example I gave in the past to replicate the problem was https://gist.github.com/jborean93/94b3eea93dbca15e60c51247c3a7b399 but I believe the above is enough to trigger it if your host is affected.

[Xer69]

Thank you for the quick answer and sorry for the duplicate issue :(
I didn't connect to my host with WinRM, but with SSH
I try what you ask :

> Invoke-Command -ComputerName MYHOST -Command {
>>     (Start-Process cmd.exe -ArgumentList '/c exit 1' -UseNewEnvironment -Wait -PassThru).ExitCode
>> }
1
> winrs.exe -r:http://MYHOST:5985/wsman powershell.exe -Command "(Start-Process cmd.exe -Argume
ntList '/c exit 1' -UseNewEnvironment -Wait -PassThru).ExitCode"
1

I switch from SSH to winrm -> same issue.
I switch from winrm to psrp -> IT WORKS !

MYHOST | SUCCESS => {
    "changed": false,
    "failed_update_count": 0,
    "filtered_updates": {},
    "found_update_count": 0,
    "installed_update_count": 0,
    "invocation": {
        "module_args": {
            "accept_list": null,
            "category_names": [
                "CriticalUpdates",
                "SecurityUpdates",
                "UpdateRollups"
            ],
            "log_path": null,
            "reboot": false,
            "reboot_timeout": 1200,
            "reject_list": null,
            "server_selection": "default",
            "skip_optional": false,
            "state": "installed"
        }
    },
    "reboot_required": false,
    "rebooted": false,
    "updates": {}
}

I have to change some things to swith from ssh to psrp... like login/pwd creds instead of private/public keys but I have no choices I guess...

Thank you very much.

[jborean93]

Interesting that the winrs example you tried worked for you as that replicates how the winrm connection plugin works. I certainly do want to fix this problem if I can my issue is I cannot reproduce it on my end to investigate further. It would be interesting if you could try and run the gist https://gist.github.com/jborean93/94b3eea93dbca15e60c51247c3a7b399 through winrs.exe with winrs.exe -r:http://MYHOST:5985/wsman powershell.exe -ExecutionPolicy ByPass -File C:\path\on\MYHOST\script.ps1 and see if it fails or not. It is a more complex example because it does a few more things that win_updates does that might be the problem.

Are you aware of any auditing/GPOs that could be applied to your host that might be problematic? Knowing more about the environment might let me know more information about what is causing the underlying issue.

[jborean93]

Closing as no more information was provided, if you ever get back to this I can certainly reopen the issue to investigate more but unfortunately I and our CI runs are unable to reproduce the problem.

[agfafrans]

at @jborean93

Could the difference in calling the module cause this bug?
With and without ansible.windows.
The last one solved my issue.

• name: search for Microsoft Windows updates
  ansible.windows.win_updates:
  category_names: "{{ windows_update_category_names }}"
  log_path: C:\Ansible_windows_update_{{ ansible_date_time.date }}.txt
  state: searched
  register: searched_for_updates

vs

• name: search for Microsoft Windows updates
  win_updates:
  category_names: "{{ windows_update_category_names }}"
  log_path: C:\Ansible_windows_update_{{ ansible_date_time.date }}.txt
  state: searched
  register: searched_for_updates

My role error in detail

[08:21:24] win_install_updates_and_reboot_role : search for Microsoft Windows updates ...Saturday 05 October 2024 08:21:24 +0200 (0:00:09.544) 0:00:21.482 ******
<my-server-name.domain.local> Running win_updates - round 1
| my-server-name.domain.local | FAILED | 5.58s
{

• msg: Failed to start new win_updates task with Task Scheduler: Unable to find type [Ansible.Windows.Process.StartupInfo].
• exception: Traceback (most recent call last):
  File "/home/ansible/.ansible/collections/ansible_collections/ansible/windows/plugins/action/win_updates.py", line 679, in run
  result = self._run_sync(task_vars, module_options, reboot, reboot_timeout)
  File "/home/ansible/.ansible/collections/ansible_collections/ansible/windows/plugins/action/win_updates.py", line 752, in _run_sync
  update_result = self._run_updates(task_vars, module_options)
  File "/home/ansible/.ansible/collections/ansible_collections/ansible/windows/plugins/action/win_updates.py", line 848, in _run_updates
  start_result = self._execute_win_updates(
  File "/home/ansible/.ansible/collections/ansible_collections/ansible/windows/plugins/action/win_updates.py", line 946, in _execute_win_updates
  raise _ReturnResultException(msg, exception=result.get('exception', None), **extra_result)

ansible_collections.ansible.windows.plugins.action.win_updates._ReturnResultException:
Failed to start new win_updates task with Task Scheduler: Unable to find type [Ansible.Windows.Process.StartupInfo].

• found_update_count: 0
• failed_update_count: 0
• installed_update_count: 0
• updates: {
  }
• filtered_updates: {
  }
• changed: False
  }