Library\ScriptAssemblies\Assembly-CSharp.pdb: The process cannot accessg

Hi guys,
I'm having
"Library\ScriptAssemblies\Assembly-CSharp.pdb: The process cannot access the file because it is being used by another process.0 file(s) copied." error.

It happens randomly after I save scripts in IDE
I tried:

• Reimport scripts folder. This only works sometime. If not work, I have to restart Unity.
• Run Unity in administrator mode, this does not help at all.
• Remove anti virus software
• Reinstall Unity
• Reinstall Windows
• Tried different Unity versions(2020.3.18, 2020.1.26, 2020.2.0)

Can anyone help me please. Thank you.

 

I've started getting this today too. Only solution is to close and re open Unity. I don't recall updating neither rider or Unity this week. Happens with Rider 2021.1.3 and Unity 2021.1.21. Note that it just started happening random, nothing else than code changes has happened with the project.

 

I'm getting it too, same kind of symptoms. I'm on 2021.2.0b4.3123. Has been happening for a few weeks now and makes it horrible to work with. Close/re-open works mostly for me. Otherwise, closing unity and deleting Library\ScriptAssemblies\Assembly-CSharp.pdb can help a bit, but the error returns soon after.

 

Multiple devs are seeing this issue here too, also all using Rider. We are seeing it happen on 2021.2.0b14.

 

It's not Rider related, I'm on VS Code, getting same behavior. Running tests and stopping them midway locks the test assembly pdb from time to time.

A workaround is to change some file in VS Code, save it, and refocus on Unity, so it reloads the domain.

 

Started happening to me when I upgraded to from 2021.1 to 2021.2 beta. I also noticed that Unity now starts compiling as soon as you save a file, even if it's not focused. So, maybe that has something to do with it.

 

Same problem here with Unity 2021.2 stable release, actually kinda surprised not more people reported it.

I am using VS Code here, and I removed Rider package, so it must not be a Rider issue.

Plus closing VS Code / saving a changed file again doesn't fix this issue for me, I HAD TO restart Unity.

 

I've been experiencing this issue for months now. I almost always update to the latest beta release hoping its fixed but it's not. It's extremely annoying. I'm using Visual Studio.

@jRocket If you're using Visual Studio you can adjust this in Tools For Unity found in Tools>Options and setting "Refresh Unity's AssetDatabase on save" to False. I've changed this for me but I still get this error. I've even tried disabling auto-refresh of Assets in Unity itself and manually refreshing with CTRL+R. This seemed to lessen the problem a little but it still happens occasionally so I turned auto-refresh back on since that was more a hassle than a help.

With apps like SysInternals Process Explorer I can see that it's only Unity itself locking the file. I've tried stuff like using AssetDatabase.ReleaseCachedFileHandles() in an editor script so I could try calling this whenever I got the problem but that hasn't seemed to work either.

I've noticed that sometimes Unity will unlock the file itself (sometimes immediately, sometimes only after some minutes). However the error will remain in Unity so refreshing the asset database can help in those situations (By editing a script and going back to Unity, or reimporting any script in Unity).

I have a hunch that Odin Inspector might have something to do with it but I'm not sure. Do any of you use that too?

 

I don't use Odin, I have a few assembly definition in the Plugins folder but they don't usually get recompiled.

EDIT: I experience this error a lot in 2021.2 release build, feel like it happens every 10 recompile attempts. They were less frequent with b11 build.

 

The problem is that it is not easy to reproduce. Sometimes it happens after 4 code recompiles and sometimes it doesn't happen for a couple of hours. I've been trying to get a min repro project without success. I have noticed that when it happens something is stuck executing since the TaskManager shows Unity using ~30% of the CPU.

 

Bump - I've got it too, have been battling with it for the past ~two months. Really kills programming flows.
@LeonhardP I second @Rotary-Heart, it is quite random, unfortunately.
When checking which process is locking the file, it is Unity.exe itself. (through Resource Monitor -> associated handles -> searching for the name "Assembly-CSharp.pdb")

For me, there's no solution when it occurs, except for doing other random things for 3-15 minutes (yes it varies a lot), and refocusing on Unity or reimporting some random script, which provokes an attempt reload of the assemblies.

@LeonhardP I will try to report it tomorrow, thanks for your interest in this problem.

 

@LeonhardP I have just submitted a bug report with my entire project Case ID: 1376585. I hope it can get resolved, good luck with the bug hunting, and let me know if I can do more to help.

 

I may be having the same issue. However, I'm not just getting an error; there are no assemblies in the Assemblies Explorer view in Rider. It just says "Nothing to show." I can use the file picker to manually pick Assembly-Csharp.csproj, but that does nothing. Really the end result is that my breakpoints don't work, and they error with "Didn't find the associated module for breakpoint."

I'm not sure if this is a Unity or rider issue, but I've submitted a support request for Rider.

 

Went from 2021.1.27 to 2022.2.0. Same issue started appearing. ("Library\ScriptAssemblies\Assembly-CSharp.pdb: Copying the file failed: The process cannot access the file because it is being used by another process.")

Using Visual Studio 2019 (Windows 10) for coding, domain reloading disabled. Wasn't yet able to do a minimal repro, so can't do a bug report. For example if I modify source files outside of VS to trigger compliation, it doesn't seem to happen. But if change code and then compile in VS, it starts happening in Unity after a some times (and doesn't go away without Unity restart). If I enable domaing reloading, it seems to stop happening again at least in my first few tests. All in all, very random and can't get a deterministic repro on it, something to do with some timing I suppose.

Edit: For whatever it's worth, had it now happen with domain reloading enabled too. Just happens more rarely then. Something to do with timing clearly. Currently my feel is that it has something to do with when I manually compile outside of Unity in VS (to check for errors before alt-tabbing to Unity) and then Unity maybe starts compiling at the same time by itself in the background and gets confused.

 

I checked in editor log, it might have something to do with Burst / IL PostProcessor

ExitCode: 3 Duration: 0s696ms

[307/324    0s] Csc Library/Bee/artifacts/1900b0aEDbg.dag/BattleSimulator.dll (+2 others)

[311/324    0s] ILPostProcess Library/Bee/artifacts/1900b0aEDbg.dag/post-processed/Assembly-CSharp-firstpass.dll (+pdb)

- Starting ILPostProcessorRunner



- Starting ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp-firstpass.dll



- Finished ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp-firstpass.dll in 0.123443 seconds



- Finished ILPostProcessorRunner in 0.145711 seconds

[311/324    0s] ILPostProcess Library/Bee/artifacts/1900b0aEDbg.dag/post-processed/Assembly-CSharp.dll (+pdb)

- Starting ILPostProcessorRunner



- Starting ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp.dll



- Finished ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp.dll in 0.118546 seconds



- Finished ILPostProcessorRunner in 0.141535 seconds

[317/324    0s] ILPostProcess Library/Bee/artifacts/1900b0aEDbg.dag/post-processed/BattleSimulator.dll (+pdb)

- Starting ILPostProcessorRunner



- Starting ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on BattleSimulator.dll



- Finished ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on BattleSimulator.dll in 0.139638 seconds



- Finished ILPostProcessorRunner in 0.166813 seconds

[319/324    0s] CopyFiles Library/ScriptAssemblies/BattleSimulator.dll

[320/324    0s] ILPostProcess Library/Bee/artifacts/1900b0aEDbg.dag/post-processed/Assembly-CSharp-Editor.dll (+pdb)

- Starting ILPostProcessorRunner



- Starting ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp-Editor.dll



- Finished ILPostProcessor 'zzzUnity.Burst.CodeGen.BurstILPostProcessor' on Assembly-CSharp-Editor.dll in 0.133814 seconds



- Finished ILPostProcessorRunner in 0.15981 seconds

[318/324    0s] CopyFiles Library/ScriptAssemblies/BattleSimulator.pdb

##### ExitCode

32

##### Output

Copying the file failed: The process cannot access the file because it is being used by another process.

*** Tundra build failed (0.58 seconds), 7 items updated, 324 evaluated

Library\ScriptAssemblies\BattleSimulator.pdb: Copying the file failed: The process cannot access the file because it is being used by another process.

Why the *&%^$ doesn't forum lets me upload .log files? This is ridiculous.

 

I also checked in windows process explorer, it's the main Unity.exe process that is holding the lock on the .pdb files.

 

This explains a lot, I use Burst quite extensively. I will see if putting them under an assembly make things better.

 

Restarting every 10 minutes is not an acceptable workflow when working on scripts.

EDIT: I also noticed if I save a script while it is recompiling, there's a 5% chance Unity will crash.

 

Having the same issue. Thought that it's related to debug mode, as PDB files contain application debugging information, but it happens in release mode too. Tried removing Library folder (among others) as this helps in some issues, but the issue persists

 

This happens on even an empty unity project. Just keep saving an empty c# file and going into the editor over and over and it WILL happen

 

Very small prototype project, also getting the same error randomly after changing code in the IDE and returning to the editor, using 2021.2.0f1, with Rider 2021.2.2, also using Burst in my project, so perhaps that's it.

Restarting Unity fixes it until the next time it happens.

 

I've been using Burst as well. I have a single Job that has the BurstCompile attribute so I created a new Assembly definition for that single script file and have not gotten the error once since then. I'm pretty sure that solved it for me.

I noticed that Burst has a 1.7.0-pre.1 update and in the changelog read the following:

I haven't updated yet since using an Assembly definition has seemed to fix it for now and the update is just a pre-release, but perhaps updating could solve it as well.

 

I have been getting the same issue for about 3 months...can we please fix this. I get this about 3~4 times a day. I have to restart the editor to get rid of this.

Here is a screenshot

 

I use Burst and gets the same issue. Perhaps it is Burst.. well, I updated burst package to 1.6.2, and I will see if it still happens...

Edit-- Updated Burst, but it still happens..

 

Can this issue be looked at ASAP ? I know Unity may be waiting for a "bug report" on this, but honestly, I could send my entire project which this happens, but it may not be reproducible at Unity side which makes the whole process so much more painful and not so encouraging.

Not very happy to rage quit Unity almost 5-10 times a day because of this.

 

I guess you could try the 1.7.0 pre release version of Burst and see if that might help?

Or you could just try making an Assembly definition for all your scripts which use Burst, as I did in my last post. That has completely solved it for me!

 

That's a solution as long as you're not working on Bursted code (or anything they depend on, like changing a shared data type, which would require the Bursted code to be recompiled). If half your codebase (or some important pieces) are Bursted, that's not much help.

That being said, this is really a design flaw in Windows/NTFS.

 

Can also confirm that once I commented out all my [BurstCompile]s, I haven't seen it happen since. Obviously not a great solution...

 

It also happens in Unity 2022.1a15

 

Happens to me too. Not using Odin. Restarting "fixes" it for some time.

Code (CSharp):

1. Library\ScriptAssemblies\Assembly-CSharp.pdb: Copying the file failed: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.
2.  

It seems recompiling is not an external process (at least a new window pops up?) which sounds like its (more) async now - I like that. But maybe it's not closing the File correctly?
Hope you fix it though.

 

Today was really hell for me with this issue. Sometimes only takes 1 or 2 compiles for this lock up to happen and then I have to restart Unity. I have been doing it over and over again for like... literally more than 100 times today. This is really really not good. Sometimes it even happened upon starting Unity when it tries to compile any script changes I made during the start up of the Unity.

 

Do you use Burst all the time? If not, have you tried disabling Burst Compilation?

 

We do need burst basically all of the time. Turning it off works around this issue but I would like to keep it on.

 

I can confirm that this happens in Alpha16 as well.

Sometimes, if I just ignore the warnings and keep working on my script in VS and save/compile, it gets out of it - not all the time. So I ended up closing the editor and making changes to the script. This is the most clean and fast way at the moment.

Please can we fix this ASAP.

In case it helps, I am using a Ryzen 5950x CPU. Just in case this is a AMD/Windows Scheduler thing. If anyone posted above is using Intel, kindly do tell

 

This looks like such a wide spread issue and we need Unity to reply on this...

 

Ryzen 9 5900x here. happens on both my work and home PCs, which are also both using the same cpu.

 

Just adding another data point to the discussion. I've been getting this bug since upgrading from 2020.3.8f1 to 2021.2.2f1. I also use Burst.

 

We just upgraded to 2021.2.4f1 and are seeing this every half hour or so. Waiting 2 minutes, changing a line of code in C#, and then refocusing on Unity seems to work around it. Interestingly enough we had a hang on occasional recompiles in 2021.1.37f before at a similar cadence, so I'm thinking this is now a visible error where before it was a hard freeze.

We are using Odin and Burst _extensively_. Burst compilation is required.

 

This has been happening to me for at least 3 months. It's very annoying. I'm also using Odin, Burst, Ryzen 5950x

 

This just started happening to me today. I imported a beta package (A* pathfinding project) and it uses burst compiler. That seems to be the common thread among those having the issue.

 

! We are also using the !* pathfinding project!

 

@LeonhardP Any update on this? Looks like a lot of people are having this issue.

 

@LeonhardP Bumping this one, experiencing the same issue frequently once I started using Burst in my project.

 

Also having this issue in latest 2021. It happens many times per day.
Any word on this?

** Edit: For anyone having this, a work around for me is to just save a script in Visual Studio, then close it and tab back into Unity. That seems to solve the issue without needing to restart the whole project.

 

For me, I haven't had the problem for a long time (~a month) when disabling Burst. So it seems to be very much tied to the use of Burst. As others have suggested: turn off Burst compilation when you're not using it.

 

It's also happening for me around 8 times a day. It's sadly very irritating ~~ (Unity 2021.2.5f1)

 

I created a new thread in Burst forum, let's see if it helps.

 

Same problem here, Unity 2021.2.5.
Regarding previous reports, I am using Rider IDE & the Burst package, no 3rd party assets.

At the moment only restart seems to fix it only for a little while. I haven't figured out what exactly triggers it.

A fix as soon as possible would be greatly appreciated, this bug is a true workflow killer.