Okay well, I suppose we can try to uninstall/reinstall but do a complete uninstall. How would I remove all traces of the program? It seems to know that Sonarr was previously installed when ever I reinstall it. Is it leaving trace folders in the registry?
No, but uninstalling won’t remove the configuration data. If you want to start from scratch you can delete/rename C:\ProgramData\NzbDrone
Not sure that will help given where it is failing (assuming it’s failing in the same place still?).
If that’s it, then you are correct. I’ve previously done that, and shortly after I started adding shows back, Sonarr would start crashing again. And yes, it still seems to be crashing at the same place.
Just wanted to check in again and see if there has been any further ideas to this issue? I would really love to start using Sonarr again.
Hello, just wanting to see if there’s anything else I can do to fix this?
@markus101 asked me to come up with some suggestions.
A memtest of < 4h is actually not all that conclusive. I’ve seen memtest detect errors well over 8h in. I’d expect other apps to run into issue as well, but if you can miss the computer for a while, run a memtest overnight. Slim chance, but little effort.
I’ve only seen one log posted related to a crash in the media cover resize logic. Are you sure it’s actually crashing in the same fashion each time?
Finally, when was the last time you updated your video driver?
Hello @Taloth
So I will run the 8hr mem test tonight and post the results tomorrow. I tried to go and create another log for you to show where it’s crashing using the following steps:
Stop Sonarr
Open Command Prompt (cmd.exe)
Run: C:\ProgramData\NzbDrone\bin\NzbDrone.Console.exe > C:\ProgramData\NzbDrone\output.txt 2>&1
I’ve attached the extremely short log it gives: https://drive.google.com/open?id=0B6SdVz5hFc0VTUhJY1p4dXZQeFU - I then end up on a page addressed as localhost:7878 but the contents of the page are blank except for the following text:
{
“message” : “NotFound”
}
So through this means, it will not even launch Sonarr anymore. Shortly after that I get a pop-up stating that NzbDrone.Host has stopped working with the only option being to “Close program”.
Lastly, I’ve just updated the video drivers and am at the most current one available - issue is still present.
I ran the MemTest over night. It found no errors (see image: https://drive.google.com/open?id=0B6SdVz5hFc0VYnlEMzY0Nm5GeDNweW1yQU9mSHdOZ0pYbDFR)
Any other suggestions? I have even started following the steps I’ve found on other sites, from other programs that experience this. (One called CoffeeCup had a thread: Uninstall, run CC to clean the registry, Uninstall .Net, restart, reinstall program to see if it works, if not, uninstall, restart, reinstall .Net, reinstall program, see if it works - sadly to no avail).
Can you go to C:\ProgramData\NzbDrone\config.xml, open in notepad. Change the <LogLevel> value to Trace. Save.
Then rename the logs directory so we’re sure to start clean.
Then Start Sonarr C:\ProgramData\NzbDrone\bin\NzbDrone.Console.exe > C:\ProgramData\NzbDrone\logs\output.txt 2>&1
Afterward, zip up the entire logs directory, you might want to PM it, considering it might contain confidential info.
I have PM’d you the requested logs (well, a link to said logs as they are not an acceptable form of media for PM’ing according to the system).
So @Taloth, any luck with the logs?
I’ve recently (for S&G’s) tried to run Sonarr in “Backwards Compatibility Mode” going as far back as WinXP (all being “Run as Administrator”) to see if that helped - sadly, the same issue still presented itself.
Hello again,
I ran a “Trace” again (link to file: https://drive.google.com/open?id=0B6SdVz5hFc0VSS1vdjdwd0NJRDg) and opened it in Notepad++. I am not entirely sure what Sonarr is doing, but there are a bunch of lines listed as: Trace|NewznabRssParser|Parsed on lines:
490-598
885-1003
1268-1379
1662-1772
2105-2235
2535-2655
I bring this up, because all the shows it’s parsing in those areas are not mine. They are not; nor have ever been on my watch list. I do not watch the shows listed there (except for Zoo - I do believe there are a couple listings of that show). So could you please help to enlighten me as to, why Sonarr is looking at shows that I don’t care about? Could this be part of the problem?
I’ll let Taloth review the logs when he can.
It’s processing the RSS feed that contains all the recently posted releases, not limited to shows you want, Sonarr needs to process every release to see if it’s for a series you want and an episode that is missing or could be upgraded. This is completely normal and not an indication of any problem.
Inbetween debugging Skyhook (took precedence), I took a peek at the logs. I hoped to see some other native stuff, but no… everything looks fine up until the point where gdi shits itself.
So I wanted to create a test app that does nothing except resize images, but haven’t gotten around to that yet.
I’m pretty much out of ideas on what could cause this. It’s practically guaranteed it’s something specific to the target system, but what is a mystery to me.
@Rexque Ok, so I wrote a test app for you: https://drive.google.com/open?id=0B_knlkUin50hUm1hZGM4VGxMN1U
(sha1 hash: 26ED83302C05EBE783C33802E40AEF5D1C92E519)
There are 3 variations of the same app, just run it in a console.
What it does is scan through C:\ProgramData\NzbDrone\MediaCover and attempts to resize all of the base images there into a temp folder in %TEMP%\sonarr-resize-test, it should automatically delete the temp folder again once finished.
It has no function other than simply resize all images and then throw em away again, but if there’s an issue with gdi and/or the resizer then we’ll know.
Thank you for continuing to look at this issue. I’ve done as you requested, and here are the results:
MediaResizeTest-4.0-3.4.3.103 - this completes fine, every time I run it (have run it 10 times with no issues).
MediaResizeTest-4.5.2-3.4.3.103 - this failed very shortly after starting. These were the results: https://drive.google.com/open?id=0B6SdVz5hFc0VVXN2aHd3T1FfYjg
MediaResizeTest-4.5.2-4.1.10 - this also failed very shortly after starting. These were the results: https://drive.google.com/open?id=0B6SdVz5hFc0VeUxteWhBZ3B3WTA
Hopefully, this will help to narrow down the issue a little.
Again - Thank you.
Just wanted to check in again to make sure you saw my reply. Sadly, there is no indicator to show if my message has been read or not.
@Rexque My apologies, I totally forgot to check back this thread after I posted the sample program. Wasn’t until I was cleaning up a directory that I ran into the test script and realized I forgot, quite embarrassing.
I don’t recall seeing a notification email either.
Thank you for running the tests, I’m happy I created those variations seeing those different results.
Interesting is that both crash when doing the same file. But more interesting is that the 4.0 version isn’t crashing.
Can you get me the content of the 100 and 106 subdirectories as shown in the screenshot? I’d like to see if the behavior is the same for me with the same input files.
Secondly can you run https://drive.google.com/open?id=0B_knlkUin50hX3FQY2E0djdBSEk (sha1 8A824F7F665E36C7D9B04E552B6DF88AB32FD8D8)
It’s a minor variation of the first case.
@markus101 What puzzles me is that the 4.0 version is basically the test app compiled against the 4.0 framework target, just like Sonarr is. The 4.5.2 versions are obviously compiled against 4.5.2 framework, but Sonarr isn’t so why are we seeing that same error in Sonarr?
The last version (3.4.3.103/4.1.10) is the ImageResizer version and evidently doesn’t affect the outcome.
Why would the framework version affect the behavior?
The only difference is that the 4.0 compiled version is 64-bit, where the rest is preferred 32-bit and so is Sonarr.
Only after realising this I created the variation posted above which is targeting x86 specifically, like Sonarr, we’ll see if it crashes. If it does then there’s likely an issue with the 32-bit gdi or related libraries.
@Taloth - Hello, No worries, life happens. I thank you for the reply.
So the 32-bit has failed. The images that were uploaded last test, and this image: https://drive.google.com/open?id=0B6SdVz5hFc0VUHRrWGk3N1UxdkE are complete with no further information available as it crashes so quick that the command line instance is short.
Here are the two directories that you requested: https://drive.google.com/open?id=0B6SdVz5hFc0VVnBicXA2eHBJY3c although it may be worth noting that if I wipe all my directories, and start new - the crashes resume after I add the first show or two, regardless of what those shows are.
The two directories doesn’t allow me to reproduce, but that was expected. Was worth a shot. It kinda proves it’s specific to your system.
So the 32-bit has failed.
So exactly what I anticipated. Fairly good news coz now we can focus our investigation.
Next thing is that we need to do is figure out exactly which libraries get loaded and which versions.
When you run the test app, it eventually waits for a keystroke. What I want you to do is, while it’s waiting:
- Go to the task manager
- ‘More details’ if you don’t have already
- Details tab
- In the list select the test app
- Right click: Create dump file
It’s crunch for a few seconds, then show a popup with the directory where it put the *.dmp file. Zip up the dump file and get it to me.
This file is a complete memory dump of the application process memory. It also contains a lot of information about which modules are loaded and, more importantly which versions.