Application crashes (visual c++ runtime library problem?)

[Antti Nopanen]

DC++ crashes after being 5 minutes running or sometimes after few hours. Every time same error message:

"
Microsoft visual c++ runtime library

This application has requested the runtime to terminate it in an unusual way. Please contact the application's support team for more information.
"

When crash occurs dc has been almost every time minimized to tray. This popup message keeps repeating and if I come to computer maybe next day there might be 10 or 30 error popus waiting for me. Also note that nearly every time when the first popup comes network traffic doesn't change so it could be assumed that it still keeps downloading your queue. After several errors downloading stops.

Backround information: I have 67 open hubs (automatically opening), hundreds of Gb:s download queue. This problem occurred when I updated to current version I'm using now. (Also note that with previous version I didn't had no more than maybe 20 open hubs simultaneusly)

DC++ version: v0.762 (r2150)
Virus scanner: AVG antivirus free
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148: version: 9.0.30729.4148 (date: 2010-05-26)
Operating system details:

"
Property Value
Name Windows 7 (Ultimate)
Features Terminal Services in Remote Admin Mode, Media Center Edition, Multiprocessor Free, OEM-Version
SKU Ultimate Edition
Checked Build No
UAC Enabled No
PAE Enabled Yes
Boot Device \Device\HarddiskVolume1
System Device \Device\HarddiskVolume2
Kernel Version 6.1.7600.16539
Security 256 bits
Product Name Windows 7 Ultimate
Build Lab 7600.win7_gdr.100226-1909

Hardware DEP Available Yes
DEP for 32 Bits Applications Yes
DEP for Drivers Yes
DEP Policy OptIn (only Windows system binaries)
Windows Update's version number 7.3.7600.16385
Automatic Updates Automatic (Recommended)
Next Detection Time 2010-06-07 06:54:50
Scheduled Install Every Day @ 3:00 AM

Restore Points
Avg Update 2010-06-02 18:50:10

Language Finnish (Finland)
Installation Time 2010-03-17 16:26:10
Boot Time 2010-06-04 18:40:54
Up Time 2 Days 15 Hours 13 Minutes 25 seconds
"

For more additional information please contact! I will be more than willing to provide any information I can!

Regards, Antti

[Antti Nopanen (antti-nopanen)]

This is only thing I got out when using mingv debug version 2159 and gdb. I did exactly as told to do in https://answers.launchpad.net/dcplusplus/+faq/337 .

Hope that this is useful for you guys if not then tell me what I'm doing wrong. :)

Regards, Antti

[eMTee (realprogger)]

You did nothing wrong it just proves what could be suspected before, that the crash isn't happen on DC++ but most probably in some application that hooks itself to DC++'s file or network I/O.

[poy (poy)]

to me this looks like DC++ is taking a code path it shouldn't, since it ends up hitting an assertion.

[eMTee (realprogger)]

oops yeah I was wrong and poy's right ;)

[Antti Nopanen (antti-nopanen)]

Referring to emtees email request. I ran DC with same hublist as before and it actually ran quite a long period of time. Not sure how many hours exactly but more than three. To me it looks different crash as before but I let you to evaluate and make your own conclusions.

See the attachment.

-Antti-

[eMTee (realprogger)]

Its actually
Assertion failed: (false && ("Add icon failed")) in dwt\ImageList.cpp, line 76

[eMTee (realprogger)]

Do these still happen using 0.770?

[carmatic (carmatic)]

Yes, DC++ 0.770 still crashes with a "Microsoft visual c++ runtime library" error

what happens during the crash is an error notification window will pop up every second or so, until there are many of these windows and DC++ finally crashes

[carmatic (carmatic)]

crashlog of latest debug build, 'this application has requested the Runtime to terminate it in an unusual way'

[eMTee (realprogger)]

What revision is your debug build? Do you have any 3rd party visual theme installed? Do you have the latest driver installed for your video card?

Does the crash still happen if you
- disable Settings/Appearence/Use system icons when browsing files
- disable Settings/Advanced/Use extended menus with icons and titles
- disable your visual theme / switch to classic visuals

[carmatic (carmatic)]

the revision of the build is the one on the 3rd november, this link http://builds.adcportal.com/dcpp/dcpp_rev_2283_mingw_debug_version.zip
(by the way, why is the debug version smaller than the release version, i thought it was the other round?)

i am not using any visual enhancements on dc++
im testing without system icons, extended menus and Aero now

[poy (poy)]

the problem here is that you are hitting an assertion in debug mode that is a no-op in release builds; so it is probably meaningless as to the actual reason of your crashes (that that assertion gets hit is a second issue).

[eMTee (realprogger)]

Please stop testing with r2283, it suffers from a serious resource leaking problem. Here's a build of r2294, use this for testing http://rghost.net/3278869 Thanks!
I meant any special 3rd party visual theme installed for Windows, btw...

[carmatic (carmatic)]

running r2294... no system icons, no extended menus, no Aero

[eMTee (realprogger)]

Can't it be that the assertion hit because of something wrong that'd cause the crash later? I mean would it be worth to provide carmatic a debug build that has the assertion check removed?

[poy (poy)]

it could be worth a short trying to run a release mode build whose debugging symbols have not been stripped off (.exe around 100MB). then once a crash happens, select "Debug the program" in the Win crash dialog, fire up "gdb DCPlusPlus.exe", attach it to the application's PID (can be found via the Task Manager) with "attach <PID>", write "continue" in GDB, hit "No" on the crash dialog debugger selector which should reproduce the crash, then finally "bt full" in GDB.
(i guess these instructions could be generalized in an FAQ for people who don't want to keep running under GDB the whole time, but just want to attach to a crashed process later on.)

a custom build without the assertion should do too. though it is likely that by the time the assert gets hit, other things have already gone wrong...

[eMTee (realprogger)]

Unstripped release build : http://rghost.net/3288438 (instructions from poy in comment #16)
Debug build with the assertion removed : http://rghost.net/3288631 (try to get the bt the same way as before)
Thanks.

[carmatic (carmatic)]

i have never seen a 'Debug the program' button in the windows crash dialog ...
so you mean, i run the 105mb dcplusplus exe file, wait for it to crash, hit 'Debug the program' and then open up a command prompt to start GDB?

[eMTee (realprogger)]

Yes, run the 105mb dcplusplus exe file, wait for it to crash, read the PID from the Task Manager PID coloumn (you may need to add the coloumn using View menu/Select Coloumns) then click 'Debug the program' (or maybe it says just 'Debug') in the crash dialog and then open up a command prompt in DC++ folder and start GDB.exe DCPlusPlus.exe...

If it doesn't work for some reason please try the second exe in the usual way. Thanks.

[carmatic (carmatic)]

the 105mb exe seems to stopped responding to right clicks on its system tray icon, and there seems to be no network traffic happening on my computer either... but there is no 'debug the program' window... this is not the first time i've seen dc++ stop resonding like this
i am going to try the second exe now

[iceman50 (bdcdevel)]

ok so while running emtee's debug build i was running my own personal clients debugging and my client crashed, i believe this to be apart of this bug report so i am posting here, if not correct me if i am wrong =)

> msvcr100d.dll!_NMSG_WRITE(int rterrnum) Line 217 C
  msvcr100d.dll!_purecall() Line 54 + 0x7 bytes C
  diceplusplus.exe!00e2bbb1()
  [Frames below may be incorrect and/or missing, no symbols loaded for diceplusplus.exe]
  diceplusplus.exe!00b0432f()
  diceplusplus.exe!00b04306()
  diceplusplus.exe!00b03691()
  diceplusplus.exe!00d8bb13()
  diceplusplus.exe!00e33d3b()
  diceplusplus.exe!00b0432f()
  diceplusplus.exe!00b04306()
  diceplusplus.exe!00b03691()
  diceplusplus.exe!00e2fc46()
  diceplusplus.exe!00e2c616()
  diceplusplus.exe!00e84353()
  diceplusplus.exe!00e18c6f()
  diceplusplus.exe!00e1641d()
  diceplusplus.exe!00e4ae37()
  kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
  ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
  ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes

- error_text 0x6b721d80 "R6025
- pure virtual function call
" const wchar_t * const
   82 L'R' const wchar_t
  msgshown 0 int

hopefully this helps more than the other debugging reports

[carmatic (carmatic)]

seems to be no different from the 'normal' debug versions i've been trying... am i missing something?

[eMTee (realprogger)]

Ive just checked, the build doesn't contain the string "Add icon failed" so it seems its not my mistake, you must have been used a wrong executable... ;)

[carmatic (carmatic)]

i am running the 105mb dcplusplus.exe again, and its gone down cold again - theres no 'debug this program' window which pops up, just the 'dc++ is not responding' dialog window

however, that window does contain this:

Problem signature:
  Problem Event Name: AppHangB1
  Application Name: DCPlusPlus.exe
  Application Version: 0.7.7.7
  Application Timestamp: 4ce41173
  Hang Signature: 5418
  Hang Type: 0
  OS Version: 6.1.7600.2.0.0.768.3
  Locale ID: 17417
  Additional Hang Signature 1: 541881a87381715b29a01e9b7e53104b
  Additional Hang Signature 2: 3a70
  Additional Hang Signature 3: 3a7017da902745178fb96a8306ff6259
  Additional Hang Signature 4: 5418
  Additional Hang Signature 5: 541881a87381715b29a01e9b7e53104b
  Additional Hang Signature 6: 3a70
  Additional Hang Signature 7: 3a7017da902745178fb96a8306ff6259

however useful it may be?

when i type 'continue' in GDB, all it says is 'Continuing.' ... i cant reproduce the crash because i dont get the debugger window... closing dc++ via the 'dc++ has stopped responding' dialog makes gdb say Program exited with code 031777777777.

[carmatic (carmatic)]

also, sorry my bad - the extracted 'debug' 108mb dcplusplus.exe does not match the md5 hash thats given on the download website, im downloading it for real now

[niblo abc (noobisgga)]

I have the same problem, but if i just left my computer alone (only dc++ running) it did not crash, or well it took a much longer time

if i run alot of things at the same time it crash more often, my guess it has to do with something being overloaded

Example something is being screwed up while refreshing, writing/reading to disk (only have one disk and therefore it is much trafik going on)

PS it does not matter what i run to make it crash more often, as long as it stress the system

[carmatic (carmatic)]

running the 'assertion removed' debug build now

it is still showing activity in gdb (UnZFilter end and NmdcHub::connectToMe messages with the occasional New Thread) , but the UI is no longer responsive - it wont minimize so i cant see my desktop, and its not drawing anything to the screen so when i drag other windows around they leave trails

[carmatic (carmatic)]

to add to my previous comment - observing the memory usage of DCplusplus.exe over a period of time seems to reveal that its continuously increasing

[poy (poy)]

can you relate these memory leaks to transfers, to some GUI element, to hubs, to a particular action?

i would double-check external apps that hook into DC++, eg ZoneAlarm & Tortoise have been pretty bad citizens in the past in that regard.

[carmatic (carmatic)]

by the time it was memory leaking, windows had already listed dc++ as not responding, i merely left it running and it crashed on its own after i've left my computer for a few hours, when i got back to it there was nothing left of the GUI
the only security software i have is microsoft security essentials

im testing r2294 again with the dc++ executable placed inside MSE's excluded processes, i wonder what difference its going to make......

[carmatic (carmatic)]

it has crashed again, it seems that trying to download with the unstripped debug build can help speed up its crash

attached is what i found in the gdb output when i scrolled up to before the endless messages like these:

UnZFilter end, 229/181 = 1.2652
UnZFilter end, 153/142 = 1.0775
UnZFilter end, 150/136 = 1.1029
NmdcHub::connectToMe XForfeonX
NmdcHub::connectToMe DamnKIDL777
UnZFilter end, 159/140 = 1.1357
UnZFilter end, 161/141 = 1.1418
UnZFilter end, 154/141 = 1.0922
UnZFilter end, 162/139 = 1.1655
UnZFilter end, 209/168 = 1.2440
UnZFilter end, 150/138 = 1.0870
UnZFilter end, 276/222 = 1.2432
UnZFilter end, 161/147 = 1.0952
UnZFilter end, 166/150 = 1.1067
UnZFilter end, 177/158 = 1.1203
UnZFilter end, 148/138 = 1.0725
UnZFilter end, 207/179 = 1.1564
UnZFilter end, 227/202 = 1.1238
UnZFilter end, 154/142 = 1.0845
NmdcHub::connectToMe Iovys
UnZFilter end, 226/178 = 1.2697
UnZFilter end, 158/148 = 1.0676
UnZFilter end, 159/148 = 1.0743
UnZFilter end, 171/151 = 1.1325
UnZFilter end, 195/162 = 1.2037
UnZFilter end, 334/252 = 1.3254
UnZFilter end, 298/217 = 1.3733
UnZFilter end, 169/152 = 1.1118
UnZFilter end, 308/242 = 1.2727
UnZFilter end, 223/179 = 1.2458
UnZFilter end, 161/142 = 1.1338
UnZFilter end, 149/137 = 1.0876
UnZFilter end, 231/184 = 1.2554
UnZFilter end, 315/232 = 1.3578
UnZFilter end, 311/246 = 1.2642
UnZFilter end, 164/147 = 1.1156
UnZFilter end, 286/227 = 1.2599
UnZFilter end, 150/139 = 1.0791
UnZFilter end, 153/140 = 1.0929
UnZFilter end, 164/148 = 1.1081
UnZFilter end, 212/179 = 1.1844
UnZFilter end, 227/181 = 1.2541
UnZFilter end, 216/181 = 1.1934

[carmatic (carmatic)]

attached is the gdb output from the 30th november build as it has crashed

[carmatic (carmatic)]

this is the crashlog for the 6th december build
i am using the mingw build, and it seems to throw up a mingw 'abort/retry/ignore' window which cannot be clicked on ...that is what is different about this build compared to the last build for which i posted a crashlog for

[eMTee (realprogger)]

Sorry but we can't see any crashlog in your last two attachment, only debug messages (which would be fine to include the last 8-10 lines only). There's no attempt to get a possible backtrace (bt full command) as well?

[carmatic (carmatic)]

i have ran the program more than once, the crashlogs are from the final times i have ran the program
typing 'bt full' always returns No Stack...

[carmatic (carmatic)]

i ran the 10th december build , and it ran for a long time before it crashed
there was a mingw assertion window, but it couldnt show anything because it has already crashed, its just a square of whatever was displayed over it before

again, bt full retrns 'no stack' ....

interestingly, typing 'r' to start dc++ again after the crash from gdb causes gdb itself to crash

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: gdb.exe
  Application Version: 0.0.0.0
  Application Timestamp: 4c94d841
  Fault Module Name: gdb.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 4c94d841
  Exception Code: c0000005
  Exception Offset: 0009e848
  OS Version: 6.1.7600.2.0.0.768.3
  Locale ID: 17417
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[carmatic (carmatic)]

this might be a stupid question, but is GDB really supposed to say

"Reading symbols from E:\DC++/dcplusplus.exe...(no debugging symbols found)...done"

??

why am i not getting any back traces when i type bt full ?

[eMTee (realprogger)]

There are several reasons you can't get a backtrace. If you use a build that doesn't contain debugging symbols (or its built using other compiler than mingw) can be one good reason...

[carmatic (carmatic)]

I would really like to submit a useful bug report, but I every 'mingw debug' version of DC++ I have downloaded gives 'no debugging symbols found' in gdb ...

[eMTee (realprogger)]

We provided you a build with with debug symbols, that should work well, no?

[Toast (swetoast-deactivatedaccount)]

my fault a new version of DC++ will be available soon on builds with debug symbols compiling as we speak :)

[eMTee (realprogger)]

Still, it would be best to use the builds we provided you above in this thread because it seems that normal debug builds are always end up in an assertion failure which does not provide us exact information.
Also, as we still in the dark about this problem, it means no fixes targeting this problem are made so far, so its improbable (though not impossible) that newer revisions fix your problem.
So it would be best to give another go to the builds made specifically to you (comment #16 & #17). They try to avoid the assertion hit in two different ways in a hope that we get more information about the crash.
You can test them in the same way as usual, as the crash FAQ descibes it...

[Toast (swetoast-deactivatedaccount)]

http://builds.adcportal.com/dcpp/dcpp_rev_2374_mingw_debug_version.zip

[poy (poy)]

rev 2380 has a good chance of fixing this (uninitialized variables were being used when creating some icons), give it a try.

[eMTee (realprogger)]

rev2381 build is available here : http://rghost.net/3878371

[eMTee (realprogger)]

...and its already on adcportal, too, so you can choose where to download from :)

[carmatic (carmatic)]

I am using 2381 now, DC++ has crashed again but what GDB shows is a bit different this time
Exception: GetIconInfo in Icon::getSize failed (The operation completed successfully.)
TimerManager done

it continued to have 'UNZFilter end' messages in GDB after that and a few occasional NmdcHub::ConnectToMe messages, but DC++ has basically crashed after the message

I killed the DC++ process with task manager so it 'exited with code 01' in GDB, and i can type stuff into the GDB command line window... typing 'bt full' returns 'no stack' ...

[carmatic (carmatic)]

after the crash, there is still some kind of network activity from DC++ , it isnt uploading as fast as its normal speed so i dont think its sharing files anymore, but judging by the Resource Monitor, as well as all the NmdcHub::connectToMe messages in GDB after the crash, i think its continuously establishing new connections to other direct connect clients after it has crashed... to think that an icon loading problem can cause the program to fail in such a way??
today DC++ crashed again, instead of killing 'dcplusplus.exe' in task manager, i decided to end the 'mingw assertion' window which was showing up under the Applications tab in task manager , as Not Responding ... this causes GDB to report

Program exited with code 031777777777.

as usual,
(gdb) BT FULL
No stack.
(gdb)

[George Michael (spacer98)]

close 10 years now i am using DC, and finally i cant remember a stable version. the website states this 770 version is the best and stable. and still we get this error. Can someone tell me which is the best fucking version without errors that just works without problems?

[Toast (swetoast-deactivatedaccount)]

much can depend on OS ie keeping updated so dropping attitude in a bugreport isnt really helpful instead get too the root of the problem with the problems you been dealing with.

ive been using DC++ for 4 years now and ive had minor issues mostly and the latest reversions haven't even crashed so my guess

lazy user + no OS updates = instable system

but again prove me wrong

[carmatic (carmatic)]

the 19th january build has a new error in gdb
warning: Invalid parameter passed to C runtime function.

it happens once every second or so, and everytime it does, DC++ opens a new error window... i had to kill DC++ with task manager, and as usual this makes bt full output no stack

i've included the nearly 1mb gdb output in case there's a clue in there about what caused it

[carmatic (carmatic)]

the major problem is that every single version of the mingw debug releases crash in a way that makes 'bt full' return 'no stack' ...

the newer builds self-terminate with code 03 after awhile and do not spawn windows during the crashes, but without the stack it makes the debugging symbols useless

[poy (poy)]

rev 2443 prevents an important resource leak, notably when hubs are reconnected a lot.

re-open this bug if crashes still happen.

[eMTee (realprogger)]

Here's a debug buid of rev 2445 to test : http://rghost.net/4589074

[poy (poy)]

Fixed in DC++ 0.782.

[carmatic (carmatic)]

actually all the previous versions before rev2445 crash

so far, 3 days of running 2445 and its not crashed yet

[eMTee (realprogger)]

Parallel tests are already confirmed that this bug is fixed and the fix is released in 0.782.
Thank you for all the testing effort anyway!