dc++ crashes/closes on restoring minimized remote desktop (mstsc)

With some more testing I found that the client actually closes already when the rdp window is minimized, not on the restore.
Same thing happens if I use another session to take over the session that DC++ is running in.

And this only happens if DC++ is the active window.

/1dat

could anyone try to reproduce this when running DC++ through GDB? this way, we'll get a call stack that will hopefully tell where the crash happens...

I have the same problem, 0.705 installed on a vista machine, logged on to via RDC. havent tried the focus yet but i will

I have the same problem. If I have DC++ as the top-most window when I minimize the RDP window, DC++ will crash. I get a Visual C++ runtime error.

I am using Win XP (on both machines involved) and the DC++ version is 0.705

Workes well, application not crashing/exiting, when using "mstsc.exe /console".

So my tip: try using the console :-)

OK, that was strange... workes sometimes with /console?

Anyone else tried it and succeeded?

i'm using /console only ... how else do you wanna connect to the account where dc++ was running, haven't tried without /console to be honest.

this afternoon i'll do some more tests as requested :)

here is the HiJackThis log as requested.

Same Problem here on a Windows 2003 TS. When minimizing the Client Window DC++ craches.

Hi guys, I've registered just to help on this one as it really annoys me that I cannot use DC no more (first time since all releases I've used).

I've verified the problem by using RDP (mstsc.exe) in both Windows XP an Windows 2003.

I'm not an experienced programmer, but I have some knowledge; so I managed to download revision 1107 and compile a debug release. The full output to the console, from start to crash, can be found attached (this was on a WinXP machine).

This doesn't tell me anything, I haven't bothered even looking into the source yet. But maybe this can tell you guys something..

Anyway, I see you guys request a stack trace; I've downloaded gdb, but I have no Idea about how to use it yet. If someone could give me a heads up, I may be able to supply a stack trace..

A quick google result : http://www.cs.cmu.edu/~gilpin/tutorial/
If you can please log on to the public devhub either ( adc://devpublic.myhub.org:16591 )

I managed to run DCpp from within gdb, but did't do much.
I've attached the new console output.

Actually, I can reproduce the crash just by locking my computer.
Hitting Ctrl+Del and selecting "Lock Computer", causes the same problem.

Does "Program exited with code 03." tell us anything?

Additional info on the bug:
 - just hitting Ctrl+Alt+Del and canceling out seems to cause the crash.
 - If the window is minimized to tray the program does not crash.

Ok, so I'll guess I'll try to explain what I've found during my (clueless?) investigations, again this is revision 1107:
Tracing what was logged to console "terminate called after throwing an instance of 'dwt::xCeption'", I've found that the exception is thrown by the function "void blast( const Rectangle & rectangle )" declared in the file "dwt\include\dwt\CanvasClasses.h". The blast() function is called at the end of the function "bool handleDrawItem(int id, LPDRAWITEMSTRUCT drawInfo)" declared in the file "dwt\src\widgets\WidgetMenu.cpp".

I was able to set a catchpoint (via the gdb command "catch throw") when the exception is thrown (the program throws a few instances of "FileException" during startup, I just ran the gdb command "c" to continue when these occurred).
This enabled me to do several things when gdb halted execution, I ran the following gdb commands: "frame", "info frame" and "backtrace full". All output from these commands is included in the attached file. I've also attempted to reveal the contents of some of the memory addresses mentioned in the output from these commands. The different output in the attached file is separated using long lines of "=" signs.

Hopefully this will help you guys on the way. I'm not acquainted with the C++ syntax or the source code of this project, but from what I can understand the exception is thrown because the window "disappears" or has some kind of "illegal dimension"..

thanks for investigating, Pedro80. as you accurately figured out by yourself, the console output itself already tells where the bug happens: on an exception thrown in DWT when the ::BitBlt function fails for whatever reason. a simple fix would be to simple remove that exception (as well as others, there are too many in DWT...).

before that, could you try the attached patch? and report here:
- if it does solve the bug;
- what is the error code given by ::GetLastError when the ::BitBlt function fails (it should output it in the console window).

I can now (happily) confirm that this patch works!

The program remains in memory and works normally when I attempt to provoke it. The following is shown in the console window:
error in blast, this is where DC++ 0.705 stops! code: 6
error in blast, this is where DC++ 0.705 stops! code: 6
error in blast, this is where DC++ 0.705 stops! code: 6
error in blast, this is where DC++ 0.705 stops! code: 6

Thats four times for each time I hit Ctrl+Alt+Del. I.e. the requested error code is 6.
Now 'll go build myself a release version to revard myself :-D
Thanks a lot poy.

error code 6 is ERROR_INVALID_HANDLE.

in http://ftp.acc.umu.se/pub/GNOME/sources/gtk+/2.8/gtk+-2.8.5.changes Tor Lillqvist (known as "the guy who ported GIMP to Windows") writes:
"
 * gdk/win32/gdkdrawable-win32.c (blit_from_pixmap): In case
 BitBlt() fails with ERROR_INVALID_HANDLE, the most probable cause
 is that the the desktop isn't visible because the session has been
 switched, the screen is locked, or a terminal server session
 disconnected, so no error message necessary. (#137796)

 It is of course remotely possible that BitBlt() failing with
 ERROR_INVALID_HANDLE might also be caused by some other
 problem. We could strive for perfection and track whether the
 desktop is visible by using WTSRegisterSessionNotification() and
 handling WM_WTSESSION_CHANGE. I think that's overdoing it just for
 this issue, though. If we would track desktop visibility, we
 should then avoid even trying to update the display at all while
 the desktop isn't visible.
"

Is this fix public yet?

See
http://sourceforge.net/project/showfiles.php?group_id=40287&package_id=70036&release_id=669882

I run 0.75 and I got the same bug, dc++ crashed when i use rdp on the machine