microsoft / azure-pipelines-tasks

Tasks for Azure Pipelines
https://aka.ms/tfbuild
MIT License
3.5k stars 2.61k forks source link

Publish symbols fails with Encountered Win32 error '203' from method 'SymEnumSourceFiles'. #16873

Closed PeterKristiansen closed 10 months ago

PeterKristiansen commented 2 years ago

Note

Issues in this repo are for tracking bugs, feature requests and questions for the tasks in this repo

For a list:
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

If you have an issue or request for the Azure Pipelines service, use developer community instead:

https://developercommunity.visualstudio.com/spaces/21/index.html )

Required Information

Question, Bug, or Feature?
Type: Bug

Enter Task Name: PublishSymbolsV2

list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

Environment

Issue Description

We see that the Index sources and publish symbols - v2 task, started ending in warning back in May with this: `##[warning]Library dbghelp.dll is already loaded from an unexpected path. Expected 'G:\T\a3\w_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.203.0\dbghelp.dll'. Actual 'G:\T\a3\w_tasks\PublishSymbols_0675668a-7bba-4ccb-901d-5ad6554ca653\2.203.0\dbghelp.dll'.

[error]Encountered Win32 error '203' from method 'SymEnumSourceFiles'.

` On the surface at least it looks like this issue - though we are only experiencing it now https://github.com/microsoft/azure-pipelines-tasks/issues/13491.

The server is running McAfee as the virusscanner. We have verified that exempting the agent folders from virus scan had no effect on this issue. However disabling McAfee completely on the server made the issue go away.

As far as Windows updates the Servicing Stack 10.0.17763.2744 was rolled on in the period between last success and first failure.

We are unable to roll back the update and McAfee is the corporate wide chosen virus scanner on servers.

The Azure DevOps agent on its own does not appear to be the culprit. Back when the issue was detected we were running 2.200.2 - but 2.200.2 was also the agent used for the last succesful job.

Task logs

[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution] Please find the log attached as 13.zip

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Error logs

[Insert error from the logs here for a quick overview] 13.zip

isctays commented 1 year ago

i have the same issue with no luck, we tried the task v1 and v2, same result.

we excluded the agent folders in mcafee. we gave agent user permissions with full control, but same issue.

Windows Server 2019 Datacenter KB5022286 Agent Version: vsts-agent-win-x64-2.214.1

we have another Windows Server 2016, and it works there. but not over the windows 2019.

due to company policy i cannot disable the AV entirely, i will request to disable it just for testing porposes to see if that makes it work.

isctays commented 1 year ago

we disabled all security related to the AV, and it works now!

dont know what the AV is doing, but in the debug mode, i could see that besides the agent folders, the process internally uses the network service user, and part of the indexing of the symbols, there is a file being writen to the users app data temp folder:

C:\windows\ServiceProfiles\NetworkService\AppData\Local\Temp

which is not accesible without administrator permissions. so, i will give it a try to exclude this path on the AV and see how it behaves.

so far, i think this temp file should be created under the agent worker folder, to avoid any possible system access issue or blocking.

jonathanlyonmoore commented 1 year ago

I turned off Windows Defender in group policy and it still doesn't work any help? On Windows 10 Enterprise 2019 LTSC How do I use a Build Controller in Azure Devops Server 2019 since XAML Build Definitions have been deprecated? I know it was a bug in a update also I know there is the conflicting PDB extension with Protein Files I wish they would go back to the SYM file extension.

the setting is managed by your administrator I'll try this.

PublishSymbolsV2: Encountered Win32 error '203' from method SymEnumSourceFiles You might want to run this powershell helper on a clean environment.

I tried to lower the UAC to never still does not work I tried running the powershell script and get errors I don't like the powershell it is too complex I dont support the USA's anti monopoly policy is was just System Management Server if corporations would play fair.

jonathanlyonmoore commented 1 year ago

I got the symbols to publish after downgrading to TFS 2018 and SQL Server 2017 Enterprise it partially published the nuget packages. The LifeCycle for TFS 2018 is 2028 and longer that Azure Devops 2019.

Untitled4

github-actions[bot] commented 10 months ago

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days