3

After installation of KB5025229/KB5025230 we are getting errors in our software:

System.IO.IOException: The process cannot access the file '{file}' because it is being used by another process.

After de-installation of KB5025229/KB5025230 the problem is gone. The problem occurred on multiple Azure VM's with Windows Server 2019 and Windows Server 2022.

Software is a c# dotnetframework4.7 asp.net MVC website running on IIS. Problem occurs on writing a temp file; this file is opened and closed multiple times in a short time, each time new data is added to the file.

This file is stored on an Azure Storage Account File Share.

So it looks like another process is locking the file now, what process can this be? Maybe Defender checking the changed file? I looked into the changes in KB5025229 but could not see anything related to this.

Does anyone have any ideas on this?

Poiter
  • 131
  • 5
  • You're not alone. We see the same problem and error message with a .NET 4.7 Windows Service we wrote running on a Windows Server 2019 VM at a customer site. This Windows Service is simple: it polls a folder intermittently and reads files that are dropped into it and manipulates them using XSL and passes them on to a database. This service was installed years ago and was working without problems and only broke after KB5025229 was installed. Once KB5025229 was uninstalled the service works without error. The referenced {file} in our 'System.IO.IOException' error is the log file for the service. – Jeff Mergler Apr 19 '23 at 15:02
  • Do you see any additional details in the Windows Event Log when your MVC application raised the error? I've requested the Windows Event Log from my customer so I can examine it for clues. My customer also mentions that the Windows Update had something to do with Defender. – Jeff Mergler Apr 19 '23 at 15:30
  • No, nothing in the Event Log. We changed our code to work around the problem, so for now we solved it and hope its the only problem with this update! – Poiter Apr 21 '23 at 08:09
  • Hi @Poiter, can you elaborate on your code change? Did change anything related to System.IO ? – Jeff Mergler Apr 22 '23 at 01:34
  • 1
    We were writing different 'chunks' to a 'temp' file, and each time we opened and closed this file (with Syste,IO.File.Open()). Now we open this file only once until all the 'chunks' are written... – Poiter Apr 24 '23 at 13:39
  • Yeah we have Problems with this Update too! We're running an Aplicationserver that connects to an SQL Server on an other VM in the same Network etc. After the Server installed the Update in a planned restart, Its not able to connect the SQL-Server anyways. The Failure is like it was blocked by the firewall but the configuration didnt changed and its not possibly caused by the SQL Server because the other Servers which didnt got the Update are still able to connect, so thanks Microsoft... – Hio May 04 '23 at 13:34

1 Answers1

0

So it looks like an other process is locking the file now, what process can this be?

You need to enable auditing at both the system level and on the file to record this information in the event log. You can also use tools such as SysInternals ProcMon to identify file access in a more hyper-accurate manner. Given that the symptom is easily reproducible in a short period of time, it should not take long to identify the offending process.

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • For now, we solved the problem by changing our code, so we are not looking further into the cause. But thanks for the suggestion! – Poiter Apr 21 '23 at 08:15