DC++k

[Snooze]

I just wanna say thanks for this great tool ! I'v added all the Op Commands to the rightclick and its now auto timebanning all users with fake shares ! This saves me and my Ops alot of time sorting those filelists )
Great job sarf !!!


One question though.

I wanted to add a line like this to the rightclick commands:

Code: Select all

+timeban %[line:desc] %[nick] %[line:desc] !!

But this makes bots %[line:desc]'s use whats typed in the last infobox Any way around this ?

[pkarlstr]

Hi,

Got some small ideas that could be nice to have..

- When checking filelists and you get disconnected or get a "File not available" have an option so you can kick them.

Should be quite easy to implement...

- If you just get "No slots available" from a user, have an option so you send a message that you want to download the filelist, and if you cannot get the filelist within the first 20(?) minutes you kick them also... (might be good to have a seperate command that is sent to the hub for this?)

[sarf]

pkarlstr:
"File not available = cheating" is already implemented - it's just called "Assume that exceptions occurring during filelist download is cheating" or somesuch.

If you get "No slots available", are an OP and the user is a DC++ client the user is assumed to be faking (since OPs should always be able to get the filelist and small files no matter how many slots are used by the DC++ client).

I'll probably not add more automated functionality to the share checker right now - it is already eating a fair bit of my time dealing with the problems of the current (and older) version.

Snooze:
The issue you have is with DC++ original code (coded by arnetheduck). As I check the code, I can only suspect that you can not use two line commands that has the same string after the colon. Thus you should use :

Code: Select all

+timeban %[line:Time] %[nick] %[line:Reason] !!

or something similar.

Sarf
---
Did you know that if you were a kangaroo, you couldn't be a mailman?

[Snooze]

Good thinking - It worked

Thanks sarf

[[MASTER]Spookie]

Hey Sarf.

I have lot of unhandle exhaptions when i run the latest dc++k, i´m using w2k professioanal.

this happens only on your client , not the others.

any idea?

Spookie

[[MASTER]Spookie]

Grrrr bloody unhandle exhaptions .....
they are coming every 10 min, checking only new users.

need help

the dead one

[Snooze]

Your not the only one, Spookie.

I "solved" the problem by just not clicking "OK" on the error popup. The clients just keeps running and doing its job

Hope that help..

[sarf]

Hmm... I'll have to run a few endurance tests with DC++k. In the mean time, try downloading this DC++k binary file (which includes the pdb file), extract it to your DC++k directory and PMing me with the exceptioninfo (the only thing different is the pdb file which allows me to see in what methods the errors occur) after you get an unhandled exception.

Sarf
---
Second star on the right, and onward 'till dawn

[[MASTER]Spookie]

yep I will do that.

[sarf]

New version released - hopefully with a few bugs squashed.

Code: Select all

 -- 0.25104k --
* Restored upload/download limit to use old values - may not work well when you have large limits
* Second MuLTe edition
* Added yet another option to the share checker - only send fake share command if OP
   thanks to KLesK for this one
* First MuLTe edition ever!
* Added some parameters to the user command
   commands only available in the search frame
     %[size] - the size of the file in question
     %[sizeformat] - the size of the file in question, formatted to kilo/mega/giga byte
     %[slots] - the amount of slots of the user
     %[freeslots] - the amount of free slots of the user
   commands available in the hub frame and in the search frame
     %[cheatingdescription] - the cheating description (if any)
* Fixed the getTargetsBySize bug (I hope!)
   thanks to Snooze and NipponPippon

Sarf
---
I'm sorry, I become inaudible when I am shy.

[[MASTER]Spookie]

unhandle exhaptions started after 6 hours running with 25104

[Linkan]

Sarf thanks for the new version

I got unhandle exhaptions after runing 0.25104k for about 2 min, It only happens when i have "automatically check filelist on new users" turned on. when I just use /checkshare it runs without any problems.

[[MASTER]Spookie]

I can´t get "only send command when op", i can´t save it when i have marked it.

everything else will be saved but not that

greatings from the crypt

[BSOD2600]

unhandle exhaptions started after 6 hours running with 25104

Mine has been running for 12+ hours just fine in 2 hubs.

[BSOD2600]

Ok I take that back....just crashed 2x within 1 hr (after being up for a good 24+ hours)

[OLDoMiNiON]

This is all i get in the error log without the pdb file..


Unhandled Exception
Code: c0000005
Version: 0.25101k
Os: Win2000 Pro Service Pack 3
Call stack info:


i'll get you one with it asap..

[sarf]

I've fixed a few minor bugs in this release.

If you find any more unhandled exceptions, be sure to PM me with an exceptioninfo.txt file that includes the method names (e.g. you have the appropriate pdb file) - otherwise I can't do anything about it.

Release info :

Code: Select all

 -- 0.251041k --
* MuLTe edition
* Added some fixes to the share checker - it might work better now
   thanks to Snooze for the report!
* Fixed the "only when OP" checkbox - sorry about that
   thanks to NipponPippon and Spookie for this!
* Added a possible fix to the "crash when downloading new users list"

Sarf
---
A man's a man all his life; a woman's sexy until she's your wife!

[[PT]Devilishly]

Great Job!!!
I’m using DC++K 0.251 and it is a very useful tool!!!
But I still think that it could be improved. Why not create an option which would check if the version which is in the tag description is the version in the “PK� parameter???
I suggest this, because I’m also using DC++ Client detection mod, and with that version I find many users faking tags in that kind of way…

Best regards,
[PT]Devilishly

[Snooze]

This last version is GREAT !!!

I've checked 3 hubs with 1000 users+ at the same time with no problems at all !!!



Thanks for a great job sarf !!!!

[OLDoMiNiON]

yes, good call.
also, here is a list of useful checks that i made a while back:

Things to look out for in Lock/PK string variations:

- Client with DC++ tag, and random lock & pk strings
- Client w/ DC++ tag, and other non-dc++ lock & pk strings. e.g. too many "ABC"'s in pk.
- Cleint w/ DC++ tag, showing a client version different to that shown in the pk string
- Client w/ DC++ tag\NMDC, with blank lock or pk string
- Client w/ or without DC++ tag, which has a lock of all "A"'s, and a pk of all "B"'s
- Client w/ Incomplete DC++ or DC Gui tag
- Client w/o tag, with only one of either lock or pk
- Client w/o tag, with a pk string <> 16 chars in length
- Client w/o tag, with a lock string outside the min/max char length of a lock string. (whatever that is )
- Client w/o tag, with a static lock string (in NMDC it changes upon each new connection from client-client)
- Client w/o tag, with DC Gui lock and pk
- Client w/o tag, with DC++ lock and pk

[Snooze]

I'm now using it in a PtokaX hub and having some truble setting up the auto kick .... it does the msg to the user just not kicking ?!? - Onyone have any ideas ?

[[PT]Devilishly]

Another suggestion, which may be a little risky

Why not make DC++K options, only available for hubs in which you’re OP?
Like when you entered in a hub in which you were a non-OP user, the options would be unavailable.

If this were possible to be done, why not create in Search, ability to search by IP? And why not have an option to automatic kick users which were in several hubs and have an incorrect parameter “H� in the tag???(this should only be done in versions equal or above DC++ 0.24)

Those are some things which I do manually, but if it could be done by a client it would be great

About:

I'm now using it in a PtokaX hub and having some truble setting up the auto kick .... it does the msg to the user just not kicking ?!? - Onyone have any ideas ?

I don’t know… By changing to ptokax, hadn’t u also changed the commands?

Keep up the good work!!!
[PT]Devilishly

[Snooze]

yeps - i changed the commands to fit the hub ...
But as the kick command is send to the hub and not the mainchat its a little diff than the nmdc hub ..and so far i havnt found a way to make it work

[[MASTER]Spookie]

ban the fakers snooze

[sarf]

I've made a little how-to page on the "raw command". It can be found here. Check it out for some ideas about what you can do. If you have any suggestions for things I should write about on the page, feel free to tell me about it in a PM.

Sarf
---
The future ain't what it used to be.

[sarf]

Yet another version released - changelog follows :

Code: Select all

 -- 0.251042k --
* MuLTe edition
* Added a small patch to the QueueFrame which may stop Wisp's Unhandled Exceptions
   "user-less sources" are now ignored - this is merely a patch for the problem
* Added a small framework for identifying the clients of users
* Fixed so that opening filelists is no longer done in a thread with low priority
   thanks to Sedulus for pointing my lazy bum to this one
* Revamped thread priorities
   you might notice DC++ stealing a little bit more CPU now, 
    but it will hopefully be a bit faster (I made the priorities a little more granular)
* Fixed so that the README.txt file is added to the binary distribution
* Fixed (almost complete) compliance with W3C standards (yay!)

Sarf
---
Yield to temptation; it may not pass your way again.

[Shinonome]

I'm now using it in a PtokaX hub and having some truble setting up the auto kick .... it does the msg to the user just not kicking ?!? - Onyone have any ideas ?

Same here..i tried this :
$To: %[nick] From: %[mynick] $<%[mynick]> You are fakesharing - I've found that you really share %[realshareformat] and state that you share %[statedshareformat].|<%[mynick]> !kickban %[nick]|

The command need to be writed in main chat ..but it just writes it in main chat without doing anything.

Another thing it should be good is for the fakesharers log to write the same exact message you ill get in main chat ...so you know who and why.
Any suggestion on how the command for the auto kick should be?
Thx ..and your tool is saving me a lot of time ( OP in a network of 4 Hubs with over 2000 users).

[Shinonome]

I'm now using it in a PtokaX hub and having some truble setting up the auto kick .... it does the msg to the user just not kicking ?!? - Onyone have any ideas ?

Same here..i tried this :
$To: %[nick] From: %[mynick] $<%[mynick]> You are fakesharing - I've found that you really share %[realshareformat] and state that you share %[statedshareformat].|<%[mynick]> !kickban %[nick]|

The command need to be writed in main chat ..but it just writes it in main chat without doing anything.

Another thing it should be good is for the fakesharers log to write the same exact message you ill get in main chat ...so you know who and why.
Any suggestion on how the command for the auto kick should be?
Thx ..and your tool is saving me a lot of time ( OP in a network of 4 Hubs with over 2000 users).

Another thing ( but i think someone else has pointed it ) i made some test with another user ..i was faking (with 0 bytes in share) still the client has not even tried to get his list in the main hub (over 1000 users) but when we tried in a smaller hub (same circuit) i got finally his list ..but then i got that "error during decompression" error ( and not only with him).Obviously he was not kicked or anything ( ah btw i found how to do an auto kick on that hub Thx to the same user)...but im not sure if he gets the message (that's why i tried with him ).
For the autokick i used this command:

$To:...<%[mynick]> !kickban %[nick] %[line:You are fakesharing - I've found that you really share] %[realshareformat] | (note that the Kick command is before the nick instead after on the command posted in the previous page).

This work's on our Hub (PtokaX software)

[sarf]

Well, I fail to see much of a difference between your two kickban commands, except that one includes "reason strings". Oh well.

Hope you'll like the new version - it should fix some of the issues I've found.

Code: Select all

 -- 0.25105k --
* MuLTe edition (new and improved!)
* Added some more detection to the fake-share detector
   a maximum size of filelists is now enforced
    filelists larger than 10 megabytes (default setting) are considered to be faked
   if DC++k is disconnected when downloading the filelist, it is considered cheating IF
    "Assume that exceptions..." is checked
   hopefully the logging will work (not tested)
* Fixed a bug with the fake share command
   will now send the fakeshare command whenever something weird with the share is detected
   this includes whenever the filelist can not be opened

Sarf
---
Discordianism: Where reality is a figment of your imagination

[[PT]Devilishly]

Hi!!!

Regarding to this option “Assume that exceptions..." should be more like when receiving a “File not available� in getting the file list and when we’re continually receiving “Disconnected� for a x time.(x = defined time, by us).
This is just to avoid unfair kicks…

Keep up the good work,
[PT]Devilishly

PS: I'm receiving this:

Unhandled Exception
Code: c0000005
Version: 0.25105k - MuLTe edition
Os: WinXP Pro
Call stack info:
DCPlusPlus!0x00402AE4 : ?
DCPlusPlus!0x00449E15 : ?
DCPlusPlus!0x0044F8B6 : ?
DCPlusPlus!0x0044FE9B : ?
DCPlusPlus!0x0045D477 : ?
DCPlusPlus!0x0045DCCE : ?
DCPlusPlus!0x0043F4DA : ?
DCPlusPlus!0x0045D3B7 : ?
DCPlusPlus!0x004060A4 : ?

[sarf]

While your suggestion has much merit, coding it is a bit too much work right now.

I am aware of the bug in the 0.25105k version, I will release a 0.251051k version momentarily.

Changelog for v0.251051k :

Code: Select all

 -- 0.251051k --
* MuLTe edition (rather new and improved!)
* Fixed a CPU-hogging / crash bug

Sarf
---
Reality is not relevant.

[Shinonome]

While your suggestion has much merit, coding it is a bit too much work right now.

I am aware of the bug in the 0.25105k version, I will release a 0.251051k version momentarily.

Changelog for v0.251051k :

Code: Select all

 -- 0.251051k --
* MuLTe edition (rather new and improved!)
* Fixed a CPU-hogging / crash bug

Sarf
---
Reality is not relevant.

What about the Log's of the fakers found? since it would be nice to log the same message you get in main chat instead of only the name.

For the command .. the difference is only that the kick command is put here "$To:...<%[mynick]> !kickban % ....." instead of ".....%[statedshareformat].|<%[mynick]> !kickban %[nick]| " (at the start instead of the end).

[Shinonome]

Sorry i didn't see you already made it (for the logs)
But then on the last build im getting un' unhandled exception ( everytime i start checking) so i had to go back to the previous one.
This is the error log:

Unhandled Exception
Code: c0000005
Version: 0.251051k - MuLTe edition
Os: WinXP Pro Service Pack 1
Call stack info:
c:\documents\vcprojects\include\stlport\stl\_string.h(304) : _STL::basic_string<char=0x00000030,_STL::char_traits<char>=0x025EA0F8,_STL::allocator<char> >::operator=
c:\documents\vcprojects\dcplusplus\client\bufferedsocket.h(120) : BufferedSocket::connect
c:\documents\vcprojects\dcplusplus\client\downloadmanager.cpp(473) : DownloadManager::handleEndData
c:\documents\vcprojects\dcplusplus\client\searchmanager.cpp(141) : SearchManager::onData
c:\documents\vcprojects\dcplusplus\zlib\deflate.c(970) : fill_window
c:\documents\vcprojects\dcplusplus\zlib\deflate.c(1348) : deflate_slow
c:\documents\vcprojects\dcplusplus\client\cryptomanager.cpp(544) : CryptoManager::encodeHuffman


and is there a way to turn off or change the script for autokicking the "disconnected when getting a file list" ? Since sometimes could just be a problem on their side ( i know of ppl i trust and im sure they were not fakesharing or slot blocking) Im really happy with the option for the autokick of fake sharers ( and they deserve it) but why the same RAW COMMAND autokick the "disconnected" too?

Thx Again

[sarf]

The reason why I do not add a "do not consider disconnects to be cheating" is that I am running out of space on the DC++k detector page. Oh well. I'll add it as an option to the advanced page instead (defaults to on, of course).

Hmmm... what pdb file are you using? I hope that you are using this one since it seems to be... eh... nonsensical at best.

Sarf
---
"Freedom defined is freedom denied." - Illuminatus

[KLesK]

if you running out of space of the 'detector page' why not put tabs into it like this

[Shinonome]

Here it is with the one you posted ( i was using the DC++ one ..not the one you posted):

Unhandled Exception
Code: c0000005
Version: 0.251051k - MuLTe edition
Os: WinXP Pro Service Pack 1
Call stack info:
g:\coding\dc++\includes\stlport\stl\_string.h(306) : _STL::basic_string<char=0x00000030,_STL::char_traits<char>=0x01A2E130,_STL::allocator<char> >::operator=
g:\dcpp-0.25-src\client\user.cpp(157) : User::sendFakeShareCommand
g:\dcpp-0.25-src\client\downloadmanager.cpp(629) : DownloadManager::onFailed
g:\dcpp-0.25-src\client\downloadmanager.cpp(734) : DownloadManager::onAction
g:\dcpp-0.25-src\client\speaker.h(53) : Speaker<UserConnectionListener>::fire
g:\dcpp-0.25-src\client\userconnection.cpp(146) : UserConnection::onAction
g:\dcpp-0.25-src\client\speaker.h(44) : Speaker<HubManagerListener>::fire
g:\dcpp-0.25-src\client\bufferedsocket.cpp(566) : BufferedSocket::run
g:\dcpp-0.25-src\client\thread.h(139) : Thread::starter
kernel32!0x77E5D33B : RegisterWaitForInputIdle


i Hope this help's

[sarf]

Hmm... really weird.

Ah well, might as well release a new version and see if it works better.

Changelog for v0.251052k :

Code: Select all

 -- 0.251052k --
* MuLTe edition (somewhat new and with fewer bugs)
* Added some error-handling code
   thanks to Shinonome for pointing me in the right direction, even if I do not know what went wrong
* Added some more granularity to share checking
   users that disconnect you when downloading their filelist can be ignored
    (Settings->Advanced->Consider disconnecting when downloading filelist to be cheating)
* Still waiting for bug reports which make sense :)

Sarf
---
Give your child mental blocks for Christmas.

[Shinonome]

Changelog for v0.251052k :

Code: Select all

 -- 0.251052k --
* MuLTe edition (somewhat new and with fewer bugs)
* Added some error-handling code
   thanks to Shinonome for pointing me in the right direction, even if I do not know what went wrong
* Added some more granularity to share checking
   users that disconnect you when downloading their filelist can be ignored
    (Settings->Advanced->Consider disconnecting when downloading filelist to be cheating)
* Still waiting for bug reports which make sense :)

Sarf
---
Give your child mental blocks for Christmas.

Seems doesn't work ( *** User [xxxxxx] No slots available for filelist despite DC++ ) and was immediately banned.
I have tried to uncheck the box ..restart DC and retry..still banning.
Checked the box again ...restarted DC and retry ..still banning.

To tell you the truth i liked more when i could get the names with the /cheatingreport command,so i can ask some ppl to try it ..and if they don't get the list ( or waiting to get it) or they get disconnected i can always ban them.And sometimes he banned timeout connections too (could not be always cheating..and getting all complains is tiresome).


One good thing is that is not giving any error till now.Thx
I hope i don't bother too much but your client is awesome and i would like to help to be even better ( if my suggestions are good )
Cya

[sarf]

(Warning: mood is not good)

What do you mean "Seems doesn't work..." ?

Are they using DC++? You can't get their filelist? Well, sucks to be them, then, because THERE IS NO LEGAL WAY for them to prevent upload of a filelist to an OP. OK? With me here? So, in your experience, what is the problem?

1. Are they not using DC++ (of v0.181 or later) ?
2. Are you not an OP?
3. Something else?

What "box" are you talking about? The "assume exceptions..." checkbox? It has no relevance to this issue as THIS IS NOT A LEGAL (=NORMAL) BEHAVIOUR AT ALL for a DC++ client.

<ahem>

So, what is your issue with this?

Sarf
---
"So tell me, just how long have you had this feeling that no one is watching you?" - Christopher Locke, Entropy Gradient Reversals

[sarf]

Released v0.251053k.

Changelog :

Code: Select all

 -- 0.251053k --
* MuLTe edition (decaying)
* Added a lot more logging
   thanks to cyberal for suggesting this
* %[cheatingdescription] is only supposed to contain
   the reason for why DC++k considers the user cheating,
   and NOT the nick of the user in question.
   I've now fixed this in the code.
* I have had lots of bug reports, and I've decided to notify all users of DC++k that
   IF you want to send me your exceptioninfo.txt files, USE THIS PDB-FILE :
    http://www.fukt.bth.se/~k/dcpp/0.251-k-bin-pdb.rar
   if you do not use this one I will send your bug reports to the closest scrap heap

Sarf
---
Some people have one of those days. I have one of those lives.

[OLDoMiNiON]

decaying, eh?

[codigo]

It seems that, in my case, dc++k is able to resume the downloads of small to medium files (0 kb to 300 mb) but unable to resume if its any larger... any ideas?

[Shinonome]

(Warning: mood is not good)

What do you mean "Seems doesn't work..." ?

Are they using DC++? You can't get their filelist? Well, sucks to be them, then, because THERE IS NO LEGAL WAY for them to prevent upload of a filelist to an OP. OK? With me here? So, in your experience, what is the problem?

1. Are they not using DC++ (of v0.181 or later) ?
2. Are you not an OP?
3. Something else?

What "box" are you talking about? The "assume exceptions..." checkbox? It has no relevance to this issue as THIS IS NOT A LEGAL (=NORMAL) BEHAVIOUR AT ALL for a DC++ client.

<ahem>

So, what is your issue with this?

Sarf
---
"So tell me, just how long have you had this feeling that no one is watching you?" - Christopher Locke, Entropy Gradient Reversals

As i said ( and sorry i didn't wanted you to be in a bad mood)is not working the "* Added some more granularity to share checking
users that disconnect you when downloading their filelist can be ignored
(Settings->Advanced->Consider disconnecting when downloading filelist to be cheating) " and they were using (mostly )
DC++ .251. They were banned anyway even when i set to ignore them.
Yes im OP in all 4 Hub's of that network ( i don't want to advertize the Hub ).Some were banned even for just a timeout ( i was looking at it).And they got no reason of why they were banned (i tested it with a friend..but when fakesharing they got the reason).

Hope this time i was more Clear

[sarf]

codigo, this is probably due to either corrupted sources or (I would guess) that you got a huge chunk of corrupted data at the end of the larger files. Try searching for the tool "cutoff" on the boards and using that.

Hmm... strange, Shinonome. Can't say why that would occur. The check is pretty straight-forward, you see, so...

Sarf
---
"I've noticed that the press tends to be quite accurate, except when they're writing on a subject I know something about." - Keith F. Lynch

[[MASTER]Spookie]

Hey sarf

great work

I thing i have found about this only check when you are OP.
If you are regged in 1 hub the client checks all users when you use /checkshare or check new user.

Can the client see the differents between op,vip,reg?

Spookie

[Shinonome]

doesn't do that already?It has the option to send command only when OP ..and to not check OP filelist ( but as for Vip i think it ill check them as normal users).

[[MASTER]Spookie]

i know this but the client is checking users in hubs there i´m only are regged in and i have marked the box " check only when op"

[sarf]

Eh? "Check only when OP" ? Where'd you find that? Oh, you mean the "Only send command when OP" ? Well, surprise, surprise, it only affects whether the command is sent when you are an OP.
<screech> (sound of thought hitting alcohol-fogged-brain)
Oh, wait. That's not entirely true. The new situations (file not available et cetera) does not check this one.

Thanks for reminding me, Spookie!

Expect this in the next version (since I fixed it now).

Sarf
---
Paranoia doesn't mean the whole world really isn't out to get you.

[Atomic Jo]

After recompiling DC++k 0.251054 (Debug version), I launched it, connect to a local hub where I am Op in...

Two situations causes DC++k crash.
First one, when I connected, I didn't remember my user pass, so there was a delay between /password that client received and op pass was send. Just after that DC++k crashed.

Secondly, I connected correctly. I checked the user filelists without problem. I closed the hub window, closed the DC++ Mainframe but an error occured. I joined you the exceptioninfo.txt file:

Code: Select all

Unhandled Exception
  Code: c0000005
Version: 0.251054k - MuLTe edition
Os: WinXP Pro
Call stack info: 
     c:\program files\microsoft visual studio .net\vc7\atlmfc\include\atlwin.h(3026) : ATL::CWindowImplBaseT<WTL::CMDIWindow=0x01352CB8,ATL::CWinTraits<1456406528=0x00000010,64> >::WindowProc
     USER32!0x77D37B17 : SetWindowPlacement
     USER32!0x77D3CDCE : DefRawInputProc
     USER32!0x77D14435 : TranslateMessageEx
     USER32!0x77D14D38 : DispatchMessageA
     c:\dc++\dc++k\0.251054-k\windows\main.cpp(262) : Run
     c:\dc++\dc++k\0.251054-k\windows\main.cpp(316) : WinMain
     f:\vs70builds\9466\vc\crtbld\crt\src\crt0.c(251) : WinMainCRTStartup
     kernel32!0x77E5EB69 : CreateProcessInternalW

Note that "check filelist on new user" is not enabled in advanced options.
I noticed the problem often appears when a user connects very quickly to me (an op with CDM 0.181 DC++ is in the hub). Maybe this can help you.

Keep up the good work

[Atomic Jo]

Sorry to post another message (we can't edit our own posts).

I think I found another bug. Same version/configuration as above.
I connected to a hub I'm a registered user in. I send a bad password and just after it, I reconnected and send the good password. Then DC++ crashed, see the exceptioninfo.txt file to help you.

Code: Select all

Unhandled Exception
  Code: c0000005
Version: 0.251054k - MuLTe edition
Os: WinXP Pro
Call stack info: 
     ntdll!0x77F59BDD : RtlpWaitForCriticalSection
     ntdll!0x77F4B176 : RtlEnterCriticalSection
     c:\dc++\dc++k\0.251054-k\client\criticalsection.h(72) : Lock::Lock
     c:\dc++\dc++k\0.251054-k\windows\hubframe.cpp(1370) : ThreadedGetList::getUser
     c:\dc++\dc++k\0.251054-k\windows\hubframe.cpp(1396) : ThreadedGetList::run
     c:\dc++\dc++k\0.251054-k\client\thread.h(138) : Thread::starter
     kernel32!0x77E602ED : OpenConsoleW

As not a great programmer (you know that, sarf ) I can make errors. But I noticed the TreadedGetlist is created in the hubframe constructor, maybe it can be created only when the user is completely logged into the hub (after receiving the $Login/$Hello string). It's just a suggestion, I suppose you may have more experience in programming than me.

Bye [/code]