I have the same problem, running kde live:

Platform Version 4.5.66 (4.6 >= 20100825)

When I launch dolphin from konsole for the 1st time I get:

timothy@studio [~] dolphin 
timothy@studio [~] QStringList Solid::Backends::KUPnP::KUPnPManager::findDeviceByDeviceInterface(Solid::DeviceInterface::Type)  error:  "org.freedesktop.DBus.Error.ServiceUnknown" 

QStringList Solid::Backends::KUPnP::KUPnPManager::findDeviceByDeviceInterface(Solid::DeviceInterface::Type)  error:  "org.freedesktop.DBus.Error.ServiceUnknown" 

QStringList Solid::Backends::KUPnP::KUPnPManager::findDeviceByDeviceInterface(Solid::DeviceInterface::Type)  error:  "org.freedesktop.DBus.Error.ServiceUnknown" 

When I close it, I get:

dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(3720)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:

After that point, I can no longer open dolphin. As the OP said, it times out and eventually says:

timothy@studio [~] dolphin 
<unknown program name>(3781)/: Communication problem with  "dolphin" , it probably crashed. 
Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." " 

Pretty nasty bug and doesn't really throw any errors. The workaround is to log out of KDE and log back in. Or go back to Konqueror. Mildly annoying.

OK, here is [hopefully useful] backtrace of what it is waiting for when you launch it for the 2nd time:

0x00007ffff78bb588 in *__GI___poll (fds=0x7fffffffcaf0, nfds=1, timeout=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/poll.c:83
83      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/poll.c
(gdb) bt
#0  0x00007ffff78bb588 in *__GI___poll (fds=0x7fffffffcaf0, nfds=1, timeout=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/poll.c:83
#1  0x00007fffef4ec040 in socket_do_iteration (transport=0x626a20, flags=6, timeout_milliseconds=25000)
    at dbus-transport-socket.c:1066
#2  0x00007fffef4ea474 in _dbus_transport_do_iteration (transport=0x626a20, flags=6, 
    timeout_milliseconds=25000) at dbus-transport.c:956
#3  0x00007fffef4d6dee in _dbus_connection_do_iteration_unlocked (connection=0x6270d0, flags=6, 
    timeout_milliseconds=25000) at dbus-connection.c:1163
#4  0x00007fffef4d8f92 in _dbus_connection_block_pending_call (pending=0x622790) at dbus-connection.c:2335
#5  0x00007fffef4d813c in dbus_connection_send_with_reply_and_block (connection=0x6270d0, message=0x6277b0, 
    timeout_milliseconds=-1, error=0x7fffffffcd40) at dbus-connection.c:3361
#6  0x00007ffff3bf65e4 in q_dbus_connection_send_with_reply_and_block (this=0x622b90, message=..., 
    sendMode=<value optimized out>, timeout=-1) at qdbus_symbols_p.h:133
#7  QDBusConnectionPrivate::sendWithReply (this=0x622b90, message=..., sendMode=<value optimized out>, 
    timeout=-1) at qdbusintegrator.cpp:1828
#8  0x00007ffff3bf6e4c in QDBusConnectionPrivate::findMetaObject (this=0x622b90, service=..., path=..., 
    interface=..., error=<value optimized out>) at qdbusintegrator.cpp:2288
#9  0x00007ffff3c044e3 in QDBusInterfacePrivate (this=0x6228c0, serv=<value optimized out>, 
    p=<value optimized out>, iface=<value optimized out>, con=<value optimized out>) at qdbusinterface.cpp:156
#10 0x00007ffff3c045d9 in QDBusInterface (this=0x7fffffffd340, service=..., path=..., interface=..., 
    connection=<value optimized out>, parent=0x0) at qdbusinterface.cpp:219
#11 0x00007ffff565d08f in KUniqueApplication::start(QFlags<KUniqueApplication::StartFlag>) ()
   from /usr/lib/libkdeui.so.5
#12 0x00007ffff565d883 in KUniqueApplication::start() () from /usr/lib/libkdeui.so.5
#13 0x00007ffff7b94b73 in kdemain () from /usr/lib/libkdeinit4_dolphin.so
#14 0x00007ffff7811bbd in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, 
    ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=0x7fffffffdb98) at libc-start.c:226
#15 0x0000000000400789 in _start ()

Another piece of data: As long as you have at least one dolphin running, you can open additional ones. 

In other words, after login, you launch 1st dolphin and while it's open, you can launch other ones. Now you can close the original dolphin, but as long as you have at least one of them open, you can launch more.

If you close all of them, you are screwed.

After all, dolphins are the most intelligent race on this planet... Oh, wait, no... mice are. Dolphins are 2nd, followed by humans. :)

Platform Version 4.5.66 (4.6 >= 20100825) svn 1169758

I have the same problem with dolphin and others: kmix,kopete,juk(after add a folder to Folder-List),amarok etc...
I can't close dolphin, main window disappear but the program stays open, i have to kill it manually ( killall dolphin ) .

Launching with -nofork option it must be closed with ^C :

[xxxx ~]$ dolphin -nofork
....
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
dolphin(21279)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
^C
[xxxx ~]$

Oh, I didn't realize dolphin stays in memory. I confirm that running killall dolphin, I am now able to open it again (until I close all windows). Thanks jef

OK, so once you open a bunch of dolphin windows and close them all, the dolphin doesn't fully die. It stays in background waiting for something. What's it waiting for, I dunno, but following is backtrace, which hopefully someone can make sense out of:

0x00007ffff16a628c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff16a628c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007ffff3ebb73b in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x83d650, 
    time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x83d650, time=18446744073709551615)
    at thread/qwaitcondition_unix.cpp:159
#3  0x00007ffff3eba75c in QThread::wait (this=<value optimized out>, time=18446744073709551615)
    at thread/qthread_unix.cpp:619
#4  0x00007ffff3f7ae20 in ~QFileSystemWatcher (this=0x838770, __in_chrg=<value optimized out>)
    at io/qfilesystemwatcher.cpp:435
#5  0x00007ffff3fb76dc in QObjectPrivate::deleteChildren (this=0x766490) at kernel/qobject.cpp:1986
#6  0x00007ffff3fbe7cf in ~QObject (this=<value optimized out>, __in_chrg=<value optimized out>)
    at kernel/qobject.cpp:975
#7  0x00007ffff3683550 in ?? () from /usr/lib/libsolid.so.4
#8  0x00007ffff3615ace in ?? () from /usr/lib/libsolid.so.4
#9  0x00007ffff3617e26 in ?? () from /usr/lib/libsolid.so.4
#10 0x00007ffff3eb8fa3 in QThreadStorageData::finish (p=<value optimized out>) at thread/qthreadstorage.cpp:185
#11 0x00007ffff3fa9c0d in ~QCoreApplicationPrivate (this=0x62fe80, __in_chrg=<value optimized out>)
    at kernel/qcoreapplication.cpp:290
#12 0x00007ffff4960089 in ~QApplicationPrivate (this=0x62fe80, __in_chrg=<value optimized out>)
    at kernel/qapplication.cpp:193
#13 0x00007ffff3fbe811 in QScopedPointerDeleter<QObjectData>::cleanup (this=<value optimized out>, 
    __in_chrg=<value optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:62
#14 ~QScopedPointer (this=<value optimized out>, __in_chrg=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:100
#15 ~QObject (this=<value optimized out>, __in_chrg=<value optimized out>) at kernel/qobject.cpp:992
#16 0x00007ffff495f6dc in ~QApplication (this=0x7fffffffd660, __in_chrg=<value optimized out>)
    at kernel/qapplication.cpp:1122
#17 0x00007ffff7b94cd9 in kdemain () from /usr/lib/libkdeinit4_dolphin.so
#18 0x00007ffff7811bbd in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, 
    ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=0x7fffffffdb78) at libc-start.c:226
#19 0x0000000000400789 in _start ()

Please lemme know if you need any other data (including but not limited to my bank account # ;)

-TJ

Looks like it's not dolphin bug. I just found out I am experiencing same thing with amarok. I launched it and then closed. Next time I tried launching from console, tsays Amarok is already running!
I did similar backtrace as above and it looks identical (frames #0 - #16).
Yesterday, before finding this bug, I ran across a similar one, which mentioned several apps including dolphin and amarok in the description. I thought my problem was limited to dolphin and ignored it. Now I can't find it.

Could it be solid or qt bug? Seems like QFileSystemWatcher is waiting for a stray thread...

(In reply to comment #7)
> Looks like it's not dolphin bug. I just found out I am experiencing same thing
> with amarok. I launched it and then closed. Next time I tried launching from
> console, tsays Amarok is already running!
> I did similar backtrace as above and it looks identical (frames #0 - #16).
> Yesterday, before finding this bug, I ran across a similar one, which mentioned
> several apps including dolphin and amarok in the description. I thought my
> problem was limited to dolphin and ignored it. Now I can't find it.
> 
> Could it be solid or qt bug? Seems like QFileSystemWatcher is waiting for a
> stray thread...

I can confirm the same thing is happening to me on both Amarok and Dolphin on my build. I had already filled out a report listed here. They mention the dev team is aware and looking into an issue with maybe a change to UPNP implementation causing this.

https://bugs.kde.org/show_bug.cgi?id=249374

*** This bug has been marked as a duplicate of bug 249374 ***