Possible stack overflow on windows using KDEConnect with bluetooth as backend

TheFireCircle · October 14, 2026, 11:31am

As I am not sure whether the KDE bug tracker is the right place and because it would be nice if someone else could reproduce it / dig into it a bit, so I’m opening a discussion first.

I use Windows 10/11 with KDE Connect 26.08.1 and wanted to try out the bluetooth backend functionality because I was curious. But when I try to connect to my Android 16 phone with KDE Connect 1.35.17 via bluetooth the connection gets lost about 4 seconds later. I looked in the windows event log and found out that the kdeconnectd.exe crashed with a stack overflow.

STATUS_STACK_OVERFLOW | ERROR_CODE: (NTSTATUS) 0xc00000fd - A new guard page for the stack cannot be created.

with the help of AI I analyzed the crash dump and it showed that the problem may appear here: https://invent.kde.org/network/kdeconnect-kde/-/blob/e396f949ee1a0281103cb41898f41a1d0b9a780a/core/backends/bluetooth/connectionmultiplexer.cpp#L322

Further investigations showed that maybe the issue comes from the qtconnectivity code.

github.com/qt/qtconnectivity

src/bluetooth/qbluetoothsocket_winrt.cpp

c6d7471b0


      
              hr = m_socketObject->get_OutputStream(&stream);
              Q_ASSERT_SUCCEEDED(hr);
          
              qint64 bytesWritten = writeIOStream(stream, data, maxSize);
              if (bytesWritten < 0) {
                  qCWarning(QT_BT_WINDOWS) << "Socket::writeData: " << state;
                  errorString = QBluetoothSocket::tr("Cannot read while not connected");
                  q->setSocketError(QBluetoothSocket::SocketError::OperationError);
              }
          
              emit q->bytesWritten(bytesWritten);
              return bytesWritten;
          }
          
          qint64 QBluetoothSocketPrivateWinRT::readData(char *data, qint64 maxSize)
          {
              Q_Q(QBluetoothSocket);
          
              if (state != QBluetoothSocket::SocketState::ConnectedState) {
                  errorString = QBluetoothSocket::tr("Cannot read while not connected");
                  q->setSocketError(QBluetoothSocket::SocketError::OperationError);

1. `ConnectionMultiplexer` connects the socket’s `bytesWritten` signal to its own slot `bytesWritten()` (<permalink to connectionmultiplexer.cpp#L37>).
2. That slot calls `mSocket->write(to_write_bytes)` (<permalink #L322>) and only removes the written data from `to_write_bytes` after `write()` has returned (L327-331).
3. On Windows, `QBluetoothSocketPrivateWinRT::writeData()` (qtconnectivity, `src/bluetooth/qbluetoothsocket_winrt.cpp`) writes synchronously and emits `bytesWritten` before it returns.
4. So the slot is re-entered while `to_write_bytes` is still unchanged, writes the same data again, which emits `bytesWritten` again, and so on until the stack overflows.

Do you think this is a valid explanation for the problem?

What should I do next?

meven · October 14, 2026, 11:32am

Report this as a bug.

with the help of AI I analyzed the crash dump

Share the actual dump in the bug report.
Not just the AI output, it can be relevant but a human needs to see the whole picture to check.

Do you think this is a valid explanation for the problem?

Seem ok, the code is quick obvious.

Or if you can manage to test your fix suggestion, you could even send a merge request for it.

TheFireCircle · October 14, 2026, 2:00pm

Ok, as this is rather an issue in QT, should I report it there or should I (also) report it in the KDE bug tracker?

meven · October 14, 2026, 2:04pm

Report the bug to kdeconnect, let the dev figure this out when they have the time.

Most devs don’t hang on discuss.kde.org but most pay attention to bugs.kde.org.

chineduokafor · October 14, 2026, 4:23pm

If kdeconnectd.exe is hitting STATUS_STACK_OVERFLOW (0xc00000fd) around the WinRT Bluetooth stream acquisition, this often points to recursive signal/slot dispatching or an unhandled event loop when the socket state changes. To pinpoint the exact trace leading into QtConnectivity, running kdeconnectd with QT_LOGGING_RULES=“kdeconnect.=true;qt.bluetooth.windows=true” in a terminal can capture the calls immediately preceding the overflow. Submitting this directly to bugs.kde.org under KDE Connect with the full crash dump / backtrace attached is likely the best way to get Windows maintainer attention.

TheFireCircle · October 16, 2026, 4:37pm

For traceability the link to the ticket I created: https://bugs.kde.org/show_bug.cgi?id=527107