Shareaza

2.5.2.0 randomly hangs with 100% CPU use at irregular intervals (aside from the still-present hang adding a security rule). The hang resolves spontaneously after several minutes. During the hang, ProcessExplorer shows a single thread consuming the lion's share of the CPU in:

ntkrnlpa.exe!KeWaitForMultipleObjects+0xadc
ntkrnlpa.exe!KeWaitForSingleObject+0x492
ntkrnlpa.exe!KeTestAlertThread+0x78
hal.dll!KfRaiseIrql+0xd1
hal.dll!KeRaiseIrqlToSynchLevel+0x70
hal.dll!HalEndSystemInterrupt+0x73
hal.dll!HalInitializeProcessor+0xcc1
Shareaza.exe+0x33065
Shareaza.exe+0x308e7
Shareaza.exe+0x29482
Shareaza.exe+0x296ef
Shareaza.exe+0x29794
Shareaza.exe+0x2f09
Shareaza.exe+0x1795a
Shareaza.exe+0x17360
Shareaza.exe+0x16d240
Shareaza.exe+0x16d465
Shareaza.exe+0x18b073
Shareaza.exe+0x18b98a
Shareaza.exe+0x18bcb6
Shareaza.exe+0xcecd5
Shareaza.exe+0xc1858
Shareaza.exe+0x4cc14
Shareaza.exe+0x48506
Shareaza.exe+0x4b38b
Shareaza.exe+0x4b41a
USER32.dll!GetWindowLongW+0x4b3
USER32.dll!GetWindowLongW+0x58b
USER32.dll!GetMessageW+0x296
USER32.dll!DispatchMessageW+0xf
Shareaza.exe+0x53c78
Shareaza.exe+0x99437
Shareaza.exe+0x77226
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

if that's any help to you in locating a particular line of Shareaza's code.

I think there is more information required to solve this problem.
Which CPU and CPU-type do you have? You could easy find it with Speccy ( Copy and paste the CPU info with CTRL-C and CTRL-V in the Reply ).
Which Operating System do you use? Windows 2000, XP, Vista, 7?

Thanks for your info. I think problem could be identified easier if you would use last debug build. Perhaps an assert would occure and it could be reported to devs. IMHO.

KfRaiseIrql function is not a part of Shareaza but Windows hardware and drivers. So check your hard disk for errors including bad block testing and update disk or motherboard chipset drivers.

The hardware and drivers are fine -- roughly a year old, too old for a manufacturing defect not to have shown itself until now and too young for age-related problems, and nothing else (including quite-demanding games and other apps) exhibits any problem.

I've since profiled the stack of the hung thread a few other times during hangs like this, or when adding security rules, as well as when it wasn't hung. It always seems to be in the same bunch of kernel routines, so my guess is that those represent a parking area for threads that are sleeping -- for whatever reason, the problem thread and Process Explorer tend to be running on the same core, so whenever Process Explorer is awake to gather data, the problem thread has yielded the CPU.

Also, since Shareaza is (nominally) I/O bound, it stands to reason that its threads would spend the vast majority of the time sleeping near an interrupt handler waiting on an interrupt.

The last Shareaza function in the stack trace before kernel code, however, differs between the hung state and a normal state.

I run Shareaza at reduced priority because otherwise these hangs render the whole system slow (somehow, despite only saturating one of two cores). So Process Explorer works, but when it examines the Shareaza process its activity causes the OS to suspend Shareaza, so presumably that is why it's always appearing to be in kernel code. Why Process Exploder never seems to be scheduled on the [i]other core[i], I don't know. Then again, how does it get its data? Perhaps from some hook into the OS scheduler, which may not see the Shareaza thread's state except when that thread's suspended, again resulting in an observer effect that makes the thread look to be always asleep in an interrupt even when it's using nearly half the CPU.

In any event, I'd investigate the Shareaza code around the last few addresses in the trace that were still within the Shareaza binary. If it's a standard relocatable image, the offsets in that dump should be the same on any copy of (SSE, 32-bit) 2.5.2.0 running on any Windoze box.

Oh, please. You looking in wrong places. Shareaza runs in user level so it can't cause system-wide freezes. Here is a priority list you must check:
1. HDD problems including drivers: run chkdsk c: /F /R or utility which can check disk surface like HDD Regenerator.
2. Antivirus/Application level firewall incompatibility issues for example Kaspersky Antivirus is highly suspected.
3. Any other hardware problems for example broken USB-device (including flash-drivers) which causes Windows driver subsystem periodic locking.

P.S. Download debug symbols i.e. Shareaza.pdb and place it near Shareaza.exe so ProcessExplorer and any other debugging tool will load and show symbols of call stack.

I can also confirm this unresponsiveness on a core i7 based computer with 6GB of RAM...

You opinion about my security filter ?
Please send me examples of spam/malware that is not filtered.

P.S. there is nw kind of spam on Gnutella - ".zip " ".mov " and so on - so "( )$" is very helpful regex

We speaking not about Shareaza freeze due incorrect security filter but about entire computer freezing.

nope
He was able to run ProcessExplorer. And there also no post about system freeze.

r8512. I tried this with 256MB and this not has happened, and as I don't believe win2k is so good then there must be additional not mentioned condition. Perhaps this is Library content, meaning number of files. Mine was 0. Perhaps this is time of staying in net connected. mine was short. I would bet OD and Diz was days or about. Perhaps this is number of connections downloading/uploading during test.
So I can't confirm. But this only means something else can have influence then rules and searches. Or describe test conditions more precisely.

OCE, specially for u:
HOW TO RECREATE THIS:
1: CLEAR ALL YOUR SECURITY RULES
2: OPEN 3 OR MORE SEARCH TAB AND SEARCH FOR SOME VERY POPULAR THINGS LIKE "Windows 7", "Avatar DVDRip" AND SIMILAR (NO OS OR MOVIE MENTIONED)
3: THAN IMPORT SECURITY RULES FROM FILE
4: OBSERVE HOW LONG SHAREAZA IS NOT RESPONDNG
5: OPEN ONE MORE SEARCH TAB AND START SEARCHING
6: ADD ANY SECURITY RULE
7: OBSERVE HOW LONG SHAREAZA IS NOT RESPONDNG