... and what happens, if you update again?
I just tried it - when I update, the problem returns.
Can you try those steps with v3.34.1 to gather some more information:
- Open Mp3tag and choose File → Open configuration folder
- Reproduce the error
- Close Mp3tag
- Open
Mp3tagError.logfrom the config folder and check if there is more info regarding the error
Mp3tag v3.34.1 - 12.05.2026 - 10:46:32
\--------------------------------------------------------------------------------
OS-Version: Windows 11 (build 26200), 64-bit
\--------------------------------------------------------------------------------
Build: May 7 2026 17:01:45 (64-bit)
\--------------------------------------------------------------------------------
AppPath: 764.294.483.968 Bytes frei (C:\\Program Files\\Mp3tag\\)
DataPath: 764.294.483.968 Bytes frei (C:\\Users\\tinke\\AppData\\Roaming\\Mp3tag\\data\\)
TempPath: 764.294.483.968 Bytes frei (C:\\Users\\tinke\\AppData\\Local\\Temp\\Mp3tag v3.34.1\\)
================================================================================
\--------------------------------------------------------------------------------
MESSAGE
\--------------------------------------------------------------------------------
File: y:\\projects\\\_audio\\smp3file2.cpp
Line: 2466
Message: E:\\7 - Dan Music\\0 - Other\\Zulu\\Nal'ibali - IsiZulu Stories - From Iono FM\\mp3 - 100% Speed (Too Fast)\\01 - Umsila KaHaruki.mp3
000048FC at 2:49.558588
\--------------------------------------------------------------------------------
MESSAGE
\--------------------------------------------------------------------------------
File: y:\\projects\\\_audio\\smp3file2.cpp
Line: 2467
Message: Access denied
000048FC at 2:49.558619OK, thanks. Access denied looks quite definitive.
Can you try disabling Ransomware protection (Protected Folder Access) in Windows Defender? It's possible that this is revoking Mp3tag's access to the file after it acquired exclusive write access and started writing metadata.
That is EXACTLY it!!
But now what? In order to use 3.34.1, I have to leave ransomware turned off??
I'd rather just go back to using 3.34.
I discovered you can allow a specific app through controlled folder access. I did that for mp3tag and now my problem is 100% resolved!
Thank you, Florian, for the help!
Hi! Same problem here with Windows 10. But Windows Defender Ransomware Protection is off. No hints in Mp3tagError.log.
There are other hints in this thread to claim ownership etc.
If this were the same problem, then the same solution should work.
It's possible that Mp3tag v3.35-beta.2 fixes the problem for you. Please let me know.
Yes it did.
Remember, I had already found a work-around for 3.34.1 by adding MP3Tag as an "allowed app" in Windows Security.
But, in order to provide you with (hopefully helpful) developer feedback, I took the following steps:
- Deleted MP3Tag from the allowed apps, and tried again with 3.34.1, to make changes to MP3's on my E drive. Same results in MP3Tag as before - "cannot write file".
- Updated MP3Tag to V3.35-beta.2 using the link you provided.
- Tried again to make changes to MP3's on my E drive. This time - Success!
No need to go back to Windows Security and add MP3Tag again, to "allowed apps".
Looks like you completely fixed the problem!! Thank you, Florian!
-Daniel
Thank you! I was referring mostly to the issue reported by @tutner , who I assume, ran into something slightly different than you.
I might be wrong and it’s both a symptom of the same issue, but wanted to double-check anyway.
No. Didn't fix. Some things I found out:
- Files with ID3v1 tag work except Album cover
- Some things I see in Process Monitor:
Process Name: Mp3tag.exe
Date: 02.06.2026 13:38:53,8450536
Thread: 8072
Class: File System
Operation: FileSystemControl
Result: INVALID DEVICE REQUEST
Path: D:\LIBRARY\music\DJ\OEMOE\pumperl_geht_Oemoe_die_Rocksau_Gruendler_Pichler.mp3
Duration: 0.0000193
Control: 0x90390 (Device:0x9 Function:228 Method: 0)
Process Name: Mp3tag.exe
Date: 02.06.2026 13:43:13,2060364
Thread: 13492
Class: File System
Operation: DeviceIoControl
Result: INVALID PARAMETER
Path: D:\LIBRARY
Duration: 0.0000098
Control: IOCTL_MOUNTDEV_QUERY_DEVICE_NAME
But anyway: Maybe we should stop debugging for Windows 10
Do you have any additional details on the drive that's D:\LIBRARY?
Internal SATA drive. D:\ is a logical NTFS volume on same drive as system partition. Is is that what you wanted to know? Otherwise I can gladly give you more details.
I'm not getting
Operation: FileSystemControl
Result: INVALID DEVICE REQUEST
Can you post the Stack from Process Monitor so that I might get an idea about the actual FSCTL request that this log entry is referring to?
Edit: And do you experience the same issue when working with files on a different drive, e.g., C: ?