Sabnzbd Locking up Win7 64 Bit System During Unpack

[jwfl]

All-
I have been using sabnzbd for a couple years now.  I upgraded to 5.2 when this issue started.  My setup is as follows:
Windows 7 64 bit Professional
Sabnzbd 5.3
Sickbeard Alpha 522

I initially thought that it was Sickbeard causing the problem (it has a custom script).  I disabled that and ran into the same problem.  

When adding a nzb file, sabnzbd adds it to the queue and then downloads the files in a normal fashion.  It appears to complete the PAR2 check and then the sabnzbd process goes up to 100% cpu usage (for some reason the sabnzbd.exe process is a high priority process which i didnt set in the config) right after unrar.exe starts.  When I terminate unrar.exe through the task manager, it gives me this error message "Unpacking failed, [Error 299] Only part of a ReadProcessMemory or WriteProcessMemory request was completed".  This seems reasonable since the unrar process was terminated.  Logs don't seem much help but I'm happy to post whatever.

I tried reinstalling over the 5.3 installation again but I have the same problem.  Any ideas

Version: 5.3 Final
OS: Win 7 x64
Install-type: Windows Installer
Skin (if applicable): Plush
Firewall Software: None
Are you using IPV6? No
Is the issue reproducible? Yes

[shypike]

The error message is what SABnzbd receives back from Windows after unrar terminates.
So the most like suspect is unrar.exe.
We have zero control over what happens inside unrar.
You can try replacing unrar.exe with a later or earlier version.
Maybe it's worth overwriting the 64 bit version with the 32 bit one.

[jwfl]

It terminates because I terminate it through task manager.  Why would sabnzb go to 100% cpu util then while unrar is running with 0%?  It seems like there is something going on at the sabnzb level

[shypike]

The odd-ball error message is just an anomaly of the Python run-time library.
It does look like unrar goes haywire.
All SABnzbd does is wait for console output from unrar, so I see no reason
why SABnzbd would use 100% CPU time. BTW, you don't need to have high priority
to get 100% CPU time from Windows.

Is the phenomenon easy to reproduce?
If so, how? Specific NZB?
I do all my testing on a Win7-64 system and I never see such problems.
Do you use a specific virus scanner?

[jwfl]

It happens every time I have any nzb that has an archive inside it that needs to be unpacked. 

I use windows security essentials but I have it disabled.  (it happens either way)

Just took your advise and replaced the x64 unrar.exe with the 32bit version and it works.  I am happy to help troubleshoot the problem ... just let me know what log files to check or post.  It seems like it has to be sabnzb as it is the one that goes to 100% cpu usage. 

Maybe I have the wrong unrar.exe in the x64 folder through a botched installation or something.
64 bit Unrar exe details:
size: 256kb (262,144 bytes)
version: 3.91.0.0
Date modified: 6/26/2010
MD5 Checksum: C589903B74EA1EF8EF4A3F0710334797

[jan]

I am having the exact same problem. I don't remember what could have changed the behaviour of sabnzbd/unrar.
Sab versions 4.xx and 5.0 worked perfectly. Some time after an update to 5.3, sab started to behave the way you describe.

Reinstalling, removing config file etc, rolling back to version 5.0.... it all doenst help. Any ideas? I will be glad to help gather information or test possible solutions.


EDIT: Looks like i solved it. DOH! trying for days to solve the problem, and it seems the solution is as simple as renaming/removing the x64 folder where the 64-bit version of unrar.exe resides.
remove or rename: C:\Program Files (x86)\SABnzbd\win\unrar\x64

jwfl: Can you confirm that this works on your system as well?

[jwfl]

it does work but obviously there is a larger issue going on

[shypike]

unrar comes from rarlabs.
We always include fairly recent versions.
We have no control over neither the quality of unrar
nor the quality of the hardware.
Both unrar and par2 are quite good at exposing marginal hardware.
(but both have some quality issues of their own too, just as SABnzbd)