Windows update client failed to detect with error 0x80240440

Stuck with Windows Update Error 0x80240440? We can help you.

Often Windows server users end up with Windows Update Error 0x80240440 while trying to update their servers for the recent security patches.

Microsoft releases many updates for Windows on a regular basis, to enhance security and improve the working efficiency of the server.

Here at Bobcares, we get requests from our customers to fix this error as a part of Server Management Services.

Today let’s see the steps that our Support Techs follow to fix this error for our customers.

How a Typical Windows Update Error 0x80240440 looks like

The error message looks like the one given below:

Also, the windows update log located at %windir%/windowsupdate.log will report the following:

+++++++++++ PT: Synchronizing server updates +++++++++++
+ ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}, Server URL = https://fe1.update.microsoft.com/v6/ClientWebService/client.asmx
WARNING: Nws Failure: errorCode=0x803d0014
WARNING: Original error code: 0x80072efe
WARNING: There was an error communicating with the endpoint at 'https://fe1.update.microsoft.com/v6/ClientWebService/client.asmx'.
WARNING: There was an error sending the HTTP request.
WARNING: The connection with the remote endpoint was terminated.
WARNING: The connection with the server was terminated abnormally
WARNING: Web service call failed with hr = 80240440.
WARNING: Current service auth scheme='None'.
WARNING: Proxy List used: '(null)', Bypass List used: '(null)', Last Proxy used: '(null)', Last auth Schemes used: 'None'.
FATAL: OnCallFailure(hrCall, m_error) failed with hr=0x80240440
WARNING: PTError: 0x80240440
WARNING: SyncUpdates_WithRecovery failed.: 0x80240440
WARNING: Sync of Updates: 0x80240440
WARNING: SyncServerUpdatesInternal failed: 0x80240440
WARNING: Failed to synchronize, error = 0x80240440
WARNING: Exit code = 0x80240440

Common Causes for this Error

Windows Update continuously fails to search for Updates or cannot install them. The following are the common causes for this error:

1. Windows Registry
2. Windows Filesystem
3. Internet access
4. Windows Update service
5. File corruption
6. Misconfiguration
7. Adware
8. Virus and Malware

Methods to fix Windows Update Error 0x80240440

The following are some of the methods that our Support Engineers follow to fix this error:

1. Clean the Windows Update temporary cache folder

To clean the Windows Update temporary cache folder we can use the following steps:

Stop the Windows Update service

1. Firstly, type “services.msc” in the Run prompt and click OK.

2. A new window will open with all Windows services on the system.

3. Finally, right-click on the “Windows Update” service and then click Stop.

Clean the Windows Update temporary cache folder

1. Firstly, type %windir%SoftwareDistributionDataStore in Run prompt and click OK.

2. This will open Windows Explorer in the correct location.

3. We can delete all contents of this folder.

Start the Windows Update Service

1. Firstly, type “services.msc” in the Run prompt and click OK.

2. A new window will open containing all Windows services on the system.

3. Finally, right-click on “Windows Update” service and then click Start.

2. Run the System File Checker (SFC) utility

SFC utility allows us to scan for damaged Windows system files and restore them. It is an in-built tool to check the filesystem

We can use the following steps to run SFC:

1. Firstly, type “cmd” in the Run prompt and then press Ctrl+Shift+Enter to run the command as an administrator.

2. Then enter the password if prompted and click OK.

3. Finally, type the following command and press enter:

sfc /scannow

As soon as the SFC process finishes, restart the server.

3. Clean Windows Update download path

1. Firstly, type regedit in Run prompt and hit Enter.

2. Navigate to
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

3. Once we found it, search for WUServer and WIStatusServer in the right-hand pane.

4. If they are not listed, we cannot clean the download path. Otherwise, delete both.

5. Finally, restart the server.

4. Disable Application Control in Sonicwall NSA

Enabling Application Control in Sonicwall NSA can cause strange network connectivity issues. The AppControl rule that is blocking the traffic may not be visible in the list of applications, however, it can be found from the logs.

We can use the “Lookup Signature” for finding the corresponding rule. Setting the Block option to Disabled for this rule allows Windows Update to work properly.

[Need Assistance? We are available 24*7]

Conclusion

In short, we saw various methods that our Support Engineers follow to fix Windows Update Error 0x80240440

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Why did I get error 0x80240440?

Windows Update continous fails to search for Updates or cannot install them. The source of this problem could be various things as

> Windows Registry
> Windows Filesystem
> Internet access

> Windows Update service
> File corruption
> Misconfiguration
> Adware
> Virus and Malware

However, if you’re technically savvy, you can try the steps below:

We will now clean the Windows Update temporary cache folder:

1. Hold your windows-key pressed and hit «R» key simultanous.
2. A small new windows will appear.
3. Type %windir%SoftwareDistributionDataStore in this new window and click OK.
4. This will open Windows Explorer on the correct location.
5. Delete all contents of this folder. (Hint: Use Ctrl + A to select all files and folders)

Now we will start the Windows Update Service again:

1. Switch back to the windows Services.
2. Locate Windows Update.
3. Right-click on it and choose Start.

If the problem still persists, you can run the System File Checker (SFC) utility. This handy in-built tool will check your filesystem.

1. Click Start and start typing on your keyboard for «cmd».

2. In your search results cmd should show up with an black icon.
3. Right-click it and select Run as administrator.
4. If you are prompted for the admin password, enter the password and click OK.
5. A new completely black windwos will open. You can type commands directly into this window.
6. Type sfc/scannow and press Enter.
7. This process will take a long time. You can minimize this black windows and work on.

Come back to the black window after a time and check if the process finished.
As soon as the SFC process finished, restart your computer. After the restart you search for Updates again.

You are still facing the same issue?

1. Restart your computer.

Next thing is to clean Windows Update download path. These steps are only for expirienced user! If you mess up your computer with Regedit, you could loose your files! Take care or use a professional tool to investiagte your computer.

Try to search for new Updates again.

You are still facing this issue? I think this is not an usual problem and your computer should be checked by professional.
Try to look for a solution here or search further in the search box below.

Advanced information

Время прочтения
6 мин

Просмотры 252K

Windows 7 по-прежнему остается популярной операционной системой в корпоративной среде, несмотря на то, что уже вышли две новые версии клиентских ОС. Расширенная поддержка «семёрки» закончится лишь 14 января 2020 г., а это значит, что ближайшие 4 года для нее будут выходить обновления, исправляющие обнаруженные уязвимости.

Существует правило – если есть обновления, то есть и проблемы с их установкой. Давайте разберем, какие основные проблемы возникают при обновлении Windows 7 через Windows Server Update Services (WSUS) и как их исправить с наименьшими затратами.

Ошибка #1. Failed to find updates with error code 80244010

Эту ошибку вы практически гарантированно будете наблюдать на любой системе, впервые обратившейся к серверу WSUS. В WindowsUpdate.log также встретится предупреждение:
WARNING: Exceeded max server round trips

Причина проблемы в том, что список обновлений стал слишком большим, и клиент не может принять его за один заход. Подробности — blogs.technet.microsoft.com/sus/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010
Какое решение предлагает Microsoft? Если после ошибки запустить повторный поиск обновлений, то процесс загрузки метаданных продолжится с момента возникновения ошибки. Терпение господа, терпение. Три, пять попыток wuauclt /detectnow – и все образуется. Не забудьте при повторном поиске дождаться окончания предыдущего цикла поиска, иначе магия не сработает!

Ошибка #2. Не устанавливаются обновления Windows с ошибкой 0x80070308

Встречается эпизодически, и в одном случае из 100 у нее есть единственное и очень специфическое решение — удалить ключ
HKLMComponentsPendingRequired=1

Перезагрузиться. Здесь важно не переусердствовать, не следует удалять никакие другие ключи в этом разделе, даже если они вам очень не нравятся, потому что после этого обновления прекратят ставиться навсегда.

Ошибка #3. Все другие ошибки

Практически 100% других ошибок может решить System Update Readiness Tool (SURT) из статьи support.microsoft.com/en-us/kb/947821
Скачиваете пакет для вашей системы, устанавливаете, читаете лог %windir%LogsCBSCheckSUR.log и если он заканчивается примерно так:

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors

то вы наш клиент.

Проблема заключается в том, что во время установки обновлений в системе могут появиться битые файлы. Что является причиной — неисправная сеть, диск, оперативная память, сам Windows Update – выяснить не получится, а исправить ошибки для установки последующих обновлений придется.

Как правило, повреждаются *.cat, *.mum, *.manifest файлы. У кого-то повреждаются *.dll, но я на практике не сталкивался. И вроде бы средство SURT должно само исправить ошибки, поскольку внутри него есть огромный каталог эталонных файлов. Только в последний раз SURT обновлялся в октябре 2014 года, а исправлений на операционную систему с тех пор вышло бесчисленное множество, и многих файлов в каталоге не хватает.

Ниже я опишу последовательность действий, необходимых для исправления ошибок установки обновлений на Windows 7 x64 с использованием SURT. Для редакции x86 просто потребуется другой пакет SURT из KB947821.

Последовательность действий будет следующая.

1. Запустить первый проход Windows6.1-KB947821-v34-x64.msu

Пользователя от работы отвлекать не потребуется, все сделаем удаленно. Создаем следующий командный файл и запускаем его:

set machine=BUHWKS02
xcopy Windows6.1-KB947821-v34-x64.msu \%machine%admin$temp
psexec -s \%machine% wusa "c:windowstempWindows6.1-KB947821-v34-x64.msu" /quiet /norestart
pause

где BUHWKS02 – целевая машина.
Когда скрипт отработает и встанет на паузу, проверяем %windir%LogsCBSCheckSUR.log
Если ошибок не найдено – дело не в битых обновлениях.
Если он заканчивается

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors
CSI Manifest All Zeros Total count: 6
CSI Catalog Corrupt Total count: 3
Fixed: CSI Catalog Corrupt. Total count: 3
CBS MUM Corrupt Total count: 3
CBS Catalog Corrupt Total count: 3
CSI Catalog Thumbprint Invalid Total count: 1
Fixed: CSI Catalog Thumbprint Invalid. Total count: 1
Unavailable repair files:
winsxsmanifestswow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_c19fa2719495aca9.manifest
winsxsmanifestsamd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.23290_none_5e936c9c5ce2e8e6.manifest
winsxsmanifestswow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_c22840d8adb43043.manifest
winsxsmanifestsamd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_b74af81f6034eaae.manifest
winsxsmanifestsamd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.19091_none_5e0ace3543c4654c.manifest
winsxsmanifestsamd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_b7d3968679536e48.manifest
servicingpackagesPackage_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicingpackagesPackage_2_for_KB3123479~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicingpackagesPackage_for_KB3123479_SP1~31bf3856ad364e35~amd64~~6.1.1.0.mum

то будем исправлять.

2. Копируем эталонные файлы на целевую машину

Microsoft предлагает нам длинную, путанную процедуру с извлечением хороших файлов из обновлений и размещением их в определенные каталоги средства SURT. При этом пути в статьях неверные. Где-то и вовсе рекомендуют подкладывать оригинальные msu файлы.

Самый простой и правильный вариант следующий — скопировать эталонные файлы с рабочей системы:

*.mum and *.cat из C:WindowsservicingPackages складываются в %windir%TempCheckSURservicingpackages
*.manifest из C:WindowswinsxsManifests складываются в %windir%TempCheckSURwinsxsmanifests

Проблема в том, что битых файлов обычно десятки, и их очень сложно выбрать и скопировать. Тогда на помощь приходит следующий скрипт PowerShell (эталонной считается машина, с которой вы запускаете скрипт)

cls
$flag = $false
$destPC = "\BUHWKS02"
$log=get-content $($destPC + "admin$LogsCBSCheckSUR.log")
$MUMCATSource = "C:WindowsservicingPackages"
$MUMCATDest = $destpc + "admin$TempCheckSURservicingPackages"
$MANIFESTSource = "C:WindowswinsxsManifests"
$MANIFESTDest = $destpc + "admin$TempCheckSURwinsxsManifests"
If ((Test-Path -Path $MUMCATDest -PathType Container) -eq $false) {New-Item -Path $MUMCATDest -ItemType directory }
If ((Test-Path -Path $MANIFESTDest -PathType Container) -eq $false) {New-Item -Path $MANIFESTDest -ItemType directory}
foreach ($line in $log) {  
    if ($flag -eq $True){
        if ($line.trim().Length -ne 0) {        
            $fileArray=$($line.Split(""))
            $file = $FileArray[$FileArray.Length-1]
            $extArray = $file.split(".")
            $ext = $extArray[$extArray.length-1]
            if ($ext -eq "manifest") {
                Write-Warning $("Copying " + $($MANIFESTSource+$file)+" to " + $MANIFESTDest)
                Copy-Item $($MANIFESTSource+$file) $($MANIFESTDest+$file)
            }
            if (($ext -eq "mum") -or ($ext -eq "cat") ) {
                Write-Warning $("Copying " + $($MUMCATSource+$file)+" to " + $MUMCATDest)
                Copy-Item $($MUMCATSource+$file) $($MUMCATDest+$file)
            }
        }
    }
    if ($line -eq "Unavailable repair files:") {$flag = $true}    
} 

Как видите, скрипт прост и может быть легко заточен напильником под вашу инфраструктуру.

3. Запускаем второй проход Windows6.1-KB947821-v34-x64.msu

После копирования файлов мы повторно запускаем SURT, используя командный файл из первого шага. При повторном запуске средство сможет подхватить скопированные нами эталонные файлы из %windir%TempCheckSUR и заменить ими испорченные.
Если мы сделали все правильно, то %windir%LogsCBSCheckSUR.log примет следующий вид:

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2016-03-03 09:15
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
Summary:
Seconds executed: 1435
No errors detected

Теперь можно продолжить установку обновлений на целевую машину, например, следующими командными файлами:
set machine= BUHWKS02
psexec -i -s \%machine% wuauclt /detectnow
pause

Ошибка #4. Если SURT отработал нормально, а обновления все равно не ставятся

Попробуйте прибегнуть к старому приему – сбросить службу Windows Update в исходное состояние. Для этого необходимо удалить каталог %windir%SoftwareDistribution.

Создаем файл WU-cleanupCMD.cmd:
net stop wuauserv
rmdir /s /q %windir%SoftwareDistribution
net start wuauserv
wuauclt /detectnow

Запускаем:
set machine= BUHWKS02
psexec -c -s \%machine% WU-cleanupCMD.cmd
pause

После этого возникнет Ошибка #1, но как бороться с ней мы уже знаем.

Ошибка #5

Клиент исчезает из консоли WSUS. Любопытная ошибка, связанная с неправильным клонированием машин и задвоением (затроением и т.д.) идентификаторов клиентов. Решается так:

net stop wuauserv
REG DELETE "HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v SusClientId /f
REG DELETE "HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate" /v SusClientIdValidation /f
net start wuauserv
wuauclt /resetauthorization /detectnow /reportnow

Ошибка #6

GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
Windows Update Client failed to detect with error 0x80072ee2

Ошибка связана с нехваткой ресурсов в AppPool WSUS. Решение — снять лимит на потребляемую память. Как это сделать — статья.
Коротко: Открываем IIS, Application Pools, WsusPool, Advanced Settings.
Параметр Private Memory Limit устанавливаем в 0.

Продолжение темы настройки WSUS — в моей следующей статье: https://habrahabr.ru/post/329440/

PS:
Многие ошибки решены в новом клиенте WSUS:
1. KB3125574 «Windows 7 post SP1 Convenience Rollup Update». Внимательно ознакомьтесь с разделом Known issues!

Предварительно необходимо установить KB3020369 «April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2».

Удачного администрирования!

После установки нового сервера WSUS в сети нашей компании многие клиенты не смогли получить новые обновления с сервера с ошибкой 0x80244010. Как оказалось, эта ошибка характерна не только для компьютеров, обновляющихся с внутреннего сервера WSUS, но и для устройств, получающих обновления напрямую с Windows Update. Рассмотрим, основные способы исправления ошибки 0x80244010 и восстановления работоспособности системы обновлений.

Для диагностики проблемы нужно открыть лог агента обновлений WindowsUpdate.log (в Windows 7 и 8 он находится в каталоге %Windir% , а в Windows 10 его можно получить так). В журнале обновлений при этом будут присутствовать такие строки:

2018-04-10 18:40:38:994 828 11a3c PT WARNING: Exceeded max server round trips: 0x80244010
2018-04-10 18:40:38:994 828 11a3c PT WARNING: Sync of Updates: 0x80244010
2018-04-10 18:40:38:994 828 11a3c PT WARNING: SyncServerUpdatesInternal failed: 0x80244010
2018-04-10 18:40:38:994 828 11a3c Agent * WARNING: Failed to synchronize, error = 0x80244010
2018-04-10 18:40:39:024 828 11a3c Agent * WARNING: Exit code = 0x80244010
2018-04-10 18:40:39:024 828 11a3c Agent *********
2018-04-10 18:40:39:024 828 11a3c Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2018-04-10 18:40:39:024 828 11a3c Agent *************
2018-04-10 18:40:39:024 828 11a3c Agent WARNING: WU client failed Searching for update with error 0x80244010
2018-04-10 18:40:39:024 828 1017c AU >>## RESUMED ## AU: Search for updates [CallId = {128CCEAD-F84D-405E-9BC2-607D1694894B}]
2018-04-10 18:40:39:024 828 1017c AU # WARNING: Search callback failed, result = 0x80244010
2018-04-10 18:40:39:024 828 1017c AU # WARNING: Failed to find updates with error code 80244010

Наибольший интерес вызывает строка Exceeded max server round trips: 0x80244010. Т.е. превышено максимальное число обращений к серверу обновлений (WSUS) во время сканирования обновлений. Об этом же свидетельствует код ошибки Windows Update согласно таблице (SUS_E_PT_EXCEEDED_MAX_SERVER_TRIPS). Т.е. сервер отключает клиента, который превысил лимит обращений. Этот лимит обращений в протоколе получения обновлений Windows устанавливается на сервере обновлений и по умолчанию составляет 200 обращений. Также имеется лимит на максимальный размер XML файла, который клиент получает с сервера в рамках одного обращения — 200 Кб. Чем большее количество обновлений на сервере для клиента нужно проверить, тем больший размер скачиваемого XML файла. В том случае, если клиенту не удается получить необходимые данные за 200 сессий, он временно отключается от сервера и возвращает ошибку.

Эта ошибка возникает, как правило, из-за плохого или нестабильного сетевого соединения с сервером обновлений или когда клиенту нужно получить слишком большое количество обновлений (новый клиент сервера WSUS или компьютер, на котором давно не устанавливались обновлений).

Самый простой вариант попробовать на клиенте несколько раз (3-7 раз) нажать кнопку Try Again или выполнить команду

wuauclt.exe / detectnow

Важно. После каждого запуска поиска обновлений нужно выждать около 15 минут, чтобы дождаться окончания предыдущего цикла поиска обновлений).

В большинстве случаев это решает проблему, но в том случае если клиентов в сети много, такой способ решения проблемы неприемлем.

По умолчанию клиент проверяет обновления на сервере каждые 22 часа. Можно увеличить частоту таких синхронизаций с помощью групповой политики Automatic Update detection frequency (в секции Computer Configuration -> Adminsitrative Templates -> Windows Components -> Windows Update), например до 3 часов.

Также можно на стороне сервера WSUS убрать ограничение на максимальный размер XML файла, который может скачать клиент с сервера. Для этого придется выполнить следующую команду в базе данных WSUSDB.

USE SUSDB
GO
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0

Если вам не хочется менять настройки в базе WSUS, можно выполнить очистку WSUS сервера с помощью встроенного мастера очистки (Консоль Update Service -> Options -> Server Cleanup Wizard -> все опции -> Next), удалив старые, неиспользуемые и замененные обновления (особенно много мусора от обновлений MS Office). В результате такой операции, клиент Windows Update будет получать намного меньше мета-информации с WSUS сервера, и его взаимодействие должно уместиться в 200 сессий по 200кб.

Кроме того, если клиентов сервера WSUS достаточно много, можно попробовать увеличить производительность пула WsusPool согласно рекомендаций из статьи: Ошибка обновления Windows 80244022.

Если все рассмотренные способы не помогли исправить ошибку обновления на каком-то клиенте, выполните на нем скрипт сброса текущих настроек WSUS и удаления локального кэша. После чего выполните несколько циклов поиска обновлений.

Windows update client failed to detect with error 0x80240440

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have all servers in one of my environments not getting any updates. Also the CCMCACHE has not been added to in months. The only error I am seeing is in the ScanAgent.Log:

CScanJob::OnScanComplete -Scan Failed with Error=0x80240440

OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80240440

Only thing I could find on the web was to reinstall WSUS. Any other ideas on what could be causing this error? TIA

Answers

hey, can you check the locationservices.log file on the servers? any trace of wsus server ?

log will say something like WSUS Path=[server fqdn] etc etc

First, we need to check the software update status message at Monitoring node -> Deployments.

Источник

Windows Update Error 0x80240440 – How we fix this

by Sushali Dasan | Mar 24, 2021

Stuck with Windows Update Error 0x80240440? We can help you.

Often Windows server users end up with Windows Update Error 0x80240440 while trying to update their servers for the recent security patches.

Microsoft releases many updates for Windows on a regular basis, to enhance security and improve the working efficiency of the server.

Here at Bobcares, we get requests from our customers to fix this error as a part of Server Management Services.

Today let’s see the steps that our Support Techs follow to fix this error for our customers.

How a Typical Windows Update Error 0x80240440 looks like

The error message looks like the one given below:

Also, the windows update log located at %windir%/windowsupdate.log will report the following:

Common Causes for this Error

Windows Update continuously fails to search for Updates or cannot install them. The following are the common causes for this error:

1. Windows Registry
2. Windows Filesystem
3. Internet access
4. Windows Update service
5. File corruption
6. Misconfiguration
7. Adware
8. Virus and Malware

Methods to fix Windows Update Error 0x80240440

The following are some of the methods that our Support Engineers follow to fix this error:

1. Clean the Windows Update temporary cache folder

To clean the Windows Update temporary cache folder we can use the following steps:

Stop the Windows Update service

1. Firstly, type “services.msc” in the Run prompt and click OK.

2. A new window will open with all Windows services on the system.

3. Finally, right-click on the “Windows Update” service and then click Stop.

Clean the Windows Update temporary cache folder

1. Firstly, type %windir%SoftwareDistributionDataStore in Run prompt and click OK.

2. This will open Windows Explorer in the correct location.

3. We can delete all contents of this folder.

Start the Windows Update Service

1. Firstly, type “services.msc” in the Run prompt and click OK.

2. A new window will open containing all Windows services on the system.

3. Finally, right-click on “Windows Update” service and then click Start.

2. Run the System File Checker (SFC) utility

SFC utility allows us to scan for damaged Windows system files and restore them. It is an in-built tool to check the filesystem

We can use the following steps to run SFC:

1. Firstly, type “cmd” in the Run prompt and then press Ctrl+Shift+Enter to run the command as an administrator.

2. Then enter the password if prompted and click OK.

3. Finally, type the following command and press enter:

As soon as the SFC process finishes, restart the server.

3. Clean Windows Update download path

1. Firstly, type regedit in Run prompt and hit Enter.

2. Navigate to
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

3. Once we found it, search for WUServer and WIStatusServer in the right-hand pane.

4. If they are not listed, we cannot clean the download path. Otherwise, delete both.

5. Finally, restart the server.

4. Disable Application Control in Sonicwall NSA

Enabling Application Control in Sonicwall NSA can cause strange network connectivity issues. The AppControl rule that is blocking the traffic may not be visible in the list of applications, however, it can be found from the logs.

We can use the “Lookup Signature” for finding the corresponding rule. Setting the Block option to Disabled for this rule allows Windows Update to work properly.

[Need Assistance? We are available 24*7]

Conclusion

In short, we saw various methods that our Support Engineers follow to fix Windows Update Error 0x80240440

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

Windows update client failed to detect with error 0x80240440

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I have all servers in one of my environments not getting any updates. Also the CCMCACHE has not been added to in months. The only error I am seeing is in the ScanAgent.Log:

CScanJob::OnScanComplete -Scan Failed with Error=0x80240440

OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80240440

Only thing I could find on the web was to reinstall WSUS. Any other ideas on what could be causing this error? TIA

Answers

hey, can you check the locationservices.log file on the servers? any trace of wsus server ?

log will say something like WSUS Path=[server fqdn] etc etc

First, we need to check the software update status message at Monitoring node -> Deployments.

Источник

Windows update failed 0*80240440

WUA handler log : scan failed with error 0*80240440

Windows update log :

2021/05/10 21:06:55.3193030 1480 86692 WebServices WS error: There was an error communicating with the endpoint at ‘http://AUM2PRD.com:8530/ClientWebService/client.asmx’.
2021/05/10 21:06:55.3193034 1480 86692 WebServices WS error: There was an error receiving the HTTP reply.
2021/05/10 21:06:55.3193044 1480 86692 WebServices WS error: The connection with the remote endpoint was terminated.
2021/05/10 21:06:55.3193049 1480 86692 WebServices WS error: The connection with the server was terminated abnormally
2021/05/10 21:06:55.3193059 1480 86692 WebServices Web service call failed with hr = 80240440.

Please advice on the resolution.

1 answer

After searching some articles about error code 0x80240440, we could guess this issue may be related to HTTPS/SSL configuration on the web services. We could verify it as per following steps:

Kindly click Administration, and navigate to Servers and Site System Roles, click Software update point Properties, then check if Require SSL communication to the WSUS server is selected. And in IIS service, we could check SSL Settings are set as: Require SSL is ticked.

—>If Require SSL communication to the WSUS server is selected, it means that the client is required to use HTTPS to communication with WSUS/SUP, and the configuration of SSL Settings Require SSL should be ticked.

—>Or we could just uncheck the option Require SSL Communication to the WSUS server and untick the option of SSL Settings Require SSL, then check if the clients could connect to WSUS/SUP successfully.

If the response is helpful, please click «Accept Answer» and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Источник

0x80244010: Исправляем ошибку обновления Windows Update

После установки нового сервера WSUS в сети нашей компании многие клиенты не смогли получить новые обновления с сервера с ошибкой 0x80244010. Как оказалось, эта ошибка характерна не только для компьютеров, обновляющихся с внутреннего сервера WSUS, но и для устройств, получающих обновления напрямую с Windows Update. Рассмотрим, основные способы исправления ошибки 0x80244010 и восстановления работоспособности системы обновлений.

Для диагностики проблемы нужно открыть лог агента обновлений WindowsUpdate.log (в Windows 7 и 8 он находится в каталоге %Windir% , а в Windows 10 его можно получить так). В журнале обновлений при этом будут присутствовать такие строки:

2018-04-10 18:40:38:994 828 11a3c PT WARNING: Exceeded max server round trips: 0x80244010

Наибольший интерес вызывает строка Exceeded max server round trips: 0x80244010. Т.е. превышено максимальное число обращений к серверу обновлений (WSUS) во время сканирования обновлений. Об этом же свидетельствует код ошибки Windows Update согласно таблице (SUS_E_PT_EXCEEDED_MAX_SERVER_TRIPS). Т.е. сервер отключает клиента, который превысил лимит обращений. Этот лимит обращений в протоколе получения обновлений Windows устанавливается на сервере обновлений и по умолчанию составляет 200 обращений. Также имеется лимит на максимальный размер XML файла, который клиент получает с сервера в рамках одного обращения — 200 Кб. Чем большее количество обновлений на сервере для клиента нужно проверить, тем больший размер скачиваемого XML файла. В том случае, если клиенту не удается получить необходимые данные за 200 сессий, он временно отключается от сервера и возвращает ошибку.

Эта ошибка возникает, как правило, из-за плохого или нестабильного сетевого соединения с сервером обновлений или когда клиенту нужно получить слишком большое количество обновлений (новый клиент сервера WSUS или компьютер, на котором давно не устанавливались обновлений).

Самый простой вариант попробовать на клиенте несколько раз (3-7 раз) нажать кнопку Try Again или выполнить команду

В большинстве случаев это решает проблему, но в том случае если клиентов в сети много, такой способ решения проблемы неприемлем.

По умолчанию клиент проверяет обновления на сервере каждые 22 часа. Можно увеличить частоту таких синхронизаций с помощью групповой политики Automatic Update detection frequency (в секции Computer Configuration -> Adminsitrative Templates -> Windows Components -> Windows Update), например до 3 часов.

Также можно на стороне сервера WSUS убрать ограничение на максимальный размер XML файла, который может скачать клиент с сервера. Для этого придется выполнить следующую команду в базе данных WSUSDB.

USE SUSDB
GO
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0

Если вам не хочется менять настройки в базе WSUS, можно выполнить очистку WSUS сервера с помощью встроенного мастера очистки (Консоль Update Service -> Options -> Server Cleanup Wizard -> все опции -> Next), удалив старые, неиспользуемые и замененные обновления (особенно много мусора от обновлений MS Office). В результате такой операции, клиент Windows Update будет получать намного меньше мета-информации с WSUS сервера, и его взаимодействие должно уместиться в 200 сессий по 200кб.

Кроме того, если клиентов сервера WSUS достаточно много, можно попробовать увеличить производительность пула WsusPool согласно рекомендаций из статьи: Ошибка обновления Windows 80244022.

Если все рассмотренные способы не помогли исправить ошибку обновления на каком-то клиенте, выполните на нем скрипт сброса текущих настроек WSUS и удаления локального кэша. После чего выполните несколько циклов поиска обновлений.

Интересное совпадение — буквально на днях разбирался с этой проблемой.
У меня с двух моих WSUS серверов клиенты (Win 7 и 8.1) стали плохо получать обновления. Началось это где-то месяца два или три назад одновременно на всех клиентах обоих серверов. Именно на всех клиентах, а не только на вновь установленных или давно не обращавшихся. Т.е. если раньше я одобрял обновления и на следующий день они разливались по всем клиентам, то теперь по прошествии недели после одобрения обновления были установлены не на всех машинах. Если же инициировать поиск обновлений вручную, то при первой попытке вылезала вот эта вот ошибка, а со второй уже (кстати 15 минут не ждал) всё находилось.
Зачем же я собственно пишу этот комментарий? В вашей статье указано решение, но не разъяснён механизм почему надо делать так и так.
Думаю стоит разъяснить.
Как уже написано — ошибка означает, что клиент за одну попытку не может выкачать весь список обновлений. По умолчанию интервал между поиском обновлений составляет 22 часа (на самом деле в интервале между примерно 17,5 ч до 22 часа). Среднестатистический рабочий компьютер выключается на ночь, а рабочий день его составляет явно меньше 17-и часов). Таким образом за рабочий цикл поиск обновлений совершается один раз и он заканчивается неудачей. И так изо дня в день. Вся фишка заключается в том, что если запустить поиск обновлений повторно, то список качается не с начала, а _докачивается_. Таким образом нам нужно добиться того, что бы компьютеры опрашивали WSUS несколько раз за свой рабочий цикл (до перезагрузки ОС). Говоря человеческим языком — несколько раз за рабочий день. Я поставил интервал опроса 3 часа (что даёт эффективный интервал

2,5 — 3 ч), точно так же как Вы предложили. На следующий же день обновления поставились на всех компах.
Удачи!

Сергей, спасибо за ценный коммент. С Вашим уточнением логика почему компьютеры не закачивают обновления сразу становится совсем железнобетонной 🙂
В моем случае WSUS был интегрирован в SCCM в виде Software Update Point, сначала грешил на него.
PS. Забавно, что одновременно с одной и той же ошибкой WSUS бились и пришли к одинаковым, не совсем очевидным, резульатам.

Также имеется лимит на максимальный размер XML файла, который клиент получает с сервера в рамках одного обращения — 200 Кб

Откуда такая информация? У меня WSUS 6.3, и опция MaxXMLPerRequest по умолчанию установлена в 5МБ.

Где-то находил эту инфу. Да и в сети гуглится быстро.
Возможно, конечно максимальный размер XML файла зависит от версии WSUS. У меня проблема была на WSUS 3.2

для подключения к встроенной базе нужно включить пользователя в группу «wsus администраторы» (изначально в ней нет доменных пользователей и в результате авторизация не проходит)

Наверно неплохо с скрипте перед последней строкой посмотреть текущее значение:
select MaxXMLPerRequest from tbConfigurationC
Ну и рассказать про sqlcmd и WID

Начну с того, что проблема у меня пропала до каких-то изменений описанных в этой статье каким-то чудом.
Заключалась проблема в том, что после IISReset на сервере WSUS через несколько минут и попытки запустить обновление Windows перестает отвечать страница «http://msk-wsus:8530/ClientWebService/client.asmx» и не важно с клиента пытаюсь зайти на нее или с самого сервера.

Изначально у меня стояло так:
Частота поиска автоматических обновлений — 1 час
MaxXMLPerRequest = 5242880 Ответить

Вырезает теги даже обернутые в тег код почему-то😅
Напишу без знаков больше / меньше.
Отредактируйте файл config ( C:Program FilesUpdate ServicesWebServicesClientWebServiceweb.config ), заменив строку httpRuntime maxRequestLength=»4096″ на httpRuntime maxRequestLength=»204800″ executionTimeout=»7200″

Хорошо что помогло!
А в логе windowsupdate.log клиента была все таки ошибка Exceeded max server round trips или только 0x8024401c ?

В логах упоминался только 8024401C и были записи с вопросительными знаками … видимо проблема с кодировкой, но я не ковырял.
2022.10.21 20:00:52.6953012 5476 6064 ProtocolTalker *FAILED* [8024401C] CAgentProtocolTalker::GetCookie_WithRecovery failed
2022.10.21 20:00:52.6953109 5476 6064 ProtocolTalker *FAILED* [8024401C] GetCookie_WithRecovery failed
2022.10.21 20:00:52.6953161 5476 6064 ProtocolTalker *FAILED* [8024401C] RefreshCookie failed
2022.10.21 20:00:52.6953222 5476 6064 ProtocolTalker *FAILED* [8024401C] RefreshPTState failed

Источник