nRF Connect Hangs with high throughput Notification

Question

I wrote a simple application which updates a 16 bit characteristic as fast as possible (after initializing everything). Similar to the following:

do {
    err_code = ble_char_update_function(&m_service, &new_value);
} while(err_code != NRF_SUCCESS);

The function called checks if the connection is valid and if notifications are enabled. If both are it sends a notification, otherwise an error (i.e. invalid state or no resources). For the basic case I just update a counter and try and measure my throughput. On the nRFConnect Mobile application it works correctly. I see the counter value increase forever or until I disable the notification. However, the final use case for this design is to use a Windows computer running the nrf52840 dongle and nRF connect application. When I use this combination there are several notifications received and then it hangs. To be clear the peripheral is still connected but if I stop the debugger it shows nothing (addresss 0x0000000). If I try and turn on a different notification or read a char from the BLE nRF Connect for Desktop app it says there's currently a GATT operation going on...

At this point I've narrowed it down to the host application (nRFConnect). Could this be a bug? There's more information below:

Dongle: nRF52840 Dongle with latest FW.

nRF Connect v3.3.0 with latest BLE app.

nRFConnect for Desktop - BLE app log below:

2020-03-20T15:29:42.353Z DEBUG GATTC_EVT_HVX time:2020-03-20T15:29:42.352Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:18 type:1 len:6
2020-03-20T15:29:42.353Z INFO Attribute value changed, handle: 0x12, value (0x): 5D-C9-5D-C9-5D-C9
2020-03-20T15:29:42.355Z DEBUG   187/ 0 <-  [02 39 00 00 00 00 00 00 00 12 00 01 06 00 5e c9 5e c9 5e c9 ] type:     VENDOR_SPECIFIC reliable:yes seq#:5 ack#:1 payload_length:14 data_integrity:1 header_checksum:e4 err_code:0x0
2020-03-20T15:29:42.356Z DEBUG      191 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:6 payload_length:0 data_integrity:0 err_code:0x0
2020-03-20T15:29:42.356Z DEBUG GATTC_EVT_HVX time:2020-03-20T15:29:42.355Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:18 type:1 len:6
2020-03-20T15:29:42.356Z INFO Attribute value changed, handle: 0x12, value (0x): 5E-C9-5E-C9-5E-C9
2020-03-20T15:29:42.357Z DEBUG   188/ 0 <-  [02 39 00 00 00 00 00 00 00 12 00 01 06 00 5f c9 5f c9 5f c9 ] type:     VENDOR_SPECIFIC reliable:yes seq#:6 ack#:1 payload_length:14 data_integrity:1 header_checksum:e3 err_code:0x0
2020-03-20T15:29:42.357Z DEBUG      192 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:7 payload_length:0 data_integrity:0 err_code:0x0
2020-03-20T15:29:42.358Z DEBUG GATTC_EVT_HVX time:2020-03-20T15:29:42.357Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:18 type:1 len:6
2020-03-20T15:29:42.358Z INFO Attribute value changed, handle: 0x12, value (0x): 5F-C9-5F-C9-5F-C9
2020-03-20T17:20:54.820Z DEBUG      193 ->  [00 9c 00 00 01 01 00 10 00 00 00 02 00 01 01 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:1 ack#:7 payload_length:10 data_integrity:1 header_checksum:f8 err_code:0x0
2020-03-20T17:20:54.822Z DEBUG   189/ 0 <-  [N/A] type:                 ACK reliable: no seq#:0 ack#:2 payload_length:0 data_integrity:0 err_code:0x0
2020-03-20T17:20:54.822Z DEBUG   190/ 0 <-  [01 9c 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:6 data_integrity:1 header_checksum:bb err_code:0x0
2020-03-20T17:20:54.822Z DEBUG      194 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0

Custom circuit board with an nRF52840 chip and very basic code running and S140 soft device.