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

Unity Engine
1

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.

5 Likes
2

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.

3 Likes
3

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.

2 Likes
4

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

2 Likes
5

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.

5 Likes
6

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.

3 Likes
7

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.

1 Like
8

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?

1 Like
9

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.

2 Likes
10

Hi everyone,

We’re not aware of any issues that could cause this behaviour. Could you please submit bug reports for these issues, ideally with reproducibles attached?

11

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.

12

If it’s hard to reproduce, it might still be worth a shot to submit a bug report for this right after the next time this happens so we can have a look at the Editor log. Please ping me here and share the issue ID if you end up following up on that.

1 Like
13

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.

1 Like
14

@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.

4 Likes
15

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.

1 Like
16

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.

3 Likes
17

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

[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.
2 Likes
18

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

1 Like
19

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

20

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.

5 Likes