Sonarr version v2.0.0.5054: Mono version (if Sonarr is not running on Windows):
**Win 10 v1709 **: Debug:
Description of issue:
TLDR: Looks like Sonarr is crashing on resizing cover art.
I reinstalled my Windows OS on the 1st of Nov and really didn’t install any other apps except Plex, Radarr, and SAB. The only AV I have in Windows Defender. I’ve checked for updates on Windows, checked for updates on Windows that could have been installed, checked on Sonarr updates, etc. Everything was working great until it looks like the 10th when it stopped working. Looking at older logs (without debug) the last log before the crash was below
Renamed NzbDrone folder, and then copied files from Backup.
Renamed NzbDrone and started over.
All had same results. After enabling debug, it looks like the process dies when trying to resize cover art / fan art. When restarting, it stays up / working until I try to update show info.
Is this a permissions issue or something like that? I’m thinking not as the process starts via the service, which is “System”. Also, it worked before, and permissions would need to change. That said, I’m not sure where else Sonarr sits other than %programdata%, and I’ve deleted all files there.
Agreed. Just read through this. The ultimate solution here was an upgrade of Windows, which I can’t do since I’m on the most up to date version. So reading through this, I added a movie to Radarr, and crash when grabbing the info (guessing cover art).
Looking more into this, when Radarr / Sonarr crashes with a faulty module “iertutil.dll”. Now, that’s IE, and I’ve honestly never opened it on this PC, so I didn’t think about it. I tried to open IE, and it bombs out, and I honestly don’t know why it’s failing, but I’m guessing once that is fixed, Sonarr / Radarr will start working again.
Does Sonarr call anything from IE for the image processing / resizing?
The problem with the other thread was that his gdbplus library versions were not up to date and seemed to be a mix and match. The windows update was simply to get to a point that we could compare the versions again with what I had locally. The fact that the update possibly fixed the problem was just a nice surprise. (fyi, it hasn’t been confirmed yet that it fixed his problem, but I’m hopeful)
@xtremedelta The problem isn’t the same though, coz his had a clean stack trace, while yours doesn’t. But I can’t say much more based on ‘it crashed’ without any stack trace or crash memory dump.
Thanks guys. So I got it sorted. Essentially that DLL is used for some back end connectivity, not just IE (even though IE relies on it). Other things like OneDrive, Sonarr, Radarr, etc indirectly call it. I only found this by watching the process threads working real time. I’m not sure why Sonarr only called that when getting cover art, but it did. It wasn’t due to resizing, but actually pulling the art.
At any rate, a VPN client, loaded a network driver that was hosing it up. So all good now thanks for the quick replies. Hopefully this will help someone else in the future.
Glad you got it sorted out. It’s not the first time that VPN messes with things but I would’ve never guessed that since it happened during the mediacover resize.
thanks for the quick replies. Hopefully this will help someone else in the future.