nrfConnect for Desktop (Bluetooth Low Energy App) ALWAYS results in blank/white application window after some time of use

[rodims]

nRFConnect for Desktop v3.3.0 
App: Bluetooth Low Energy v2.3.2 
Windows 10 x64 ( 19.04,  19.09), using Dual Monitor. 
Device: PCA10059 or PCA10056

I can start, connect, and use the nRFConnect / Bluetooth Low Energy App without problems for some time. For a certain time it works fine and simply as expected. 
The device attached to my PC usually is a nRF52840 Dongle ( PCA10059 ), but I also verified the problem with a nRF52840 DK  (PCA10056)

But after some time the window becomes completely blank/white. 

I have seen some complaints about a white window in the forum, but none of them seems to have the problem that it first works and then turns white after some time. 
The typical scenario is: 

- Start nrfConnect for Desktop
- Start the Bluetooth Low Energy App from the list of apps
- Select the BTLE device (usually PCA10059) 
- Select "Start Scan" to discover my BTLE devices
- Connect to some BTLE device and communicate with it. 
From now on it is only a question of time (seconds to several minutes) when the client area of the Bluetoot Low Energy app window turns completely white.
May be important to mention: when the window turns white, I usually do nothing in this window.  So the problem appears without any obvious reason. 

I can close the window through the Windows captions close box, but clicking into the white window at different locations does nothing. So it's not just a simple Windows Refresh problem, minimizing and restoring the window does not help. 
What is possible is to press Ctrl-R, then the windows content will appear again, but all connections are lost. So thats not more helpful than restarting the Bluetooth Low Energy App. 

So I cannot work with this longer than 5 minutes in average until I have to restart everything. 
This problem is around since I use the nrfConnect for Windows (1 year approx) , so it was also present with previous versions and never worked for me. 

I investigated the log file, which looks ok, but the final problem is not logged there in any way. 

Is this a known problem ?
How can I get rid of this annoying problem in nrfConnect for Desktop ?

# nRFConnect System Report - 2019-12-06T20-02-51.791Z

- System:     System manufacturer System Product Name
- BIOS:       American Megatrends Inc. ALASKA - 1072009
- CPU:        1 x Intel® Core™ i7-6700 3.40 GHz 8 cores (4 physical)
- Memory:     20.6 GB free of 31.9 GB total
- Filesystem: C: (NTFS) 475.9 GB 62.8% used

- OS:         Microsoft Windows 10 Pro (10.0.18363) win32 ia32

- Versions
    - kernel: 10.0.18363
    - git: 2.12.0.windows.1
    - node: 12.0.0
    - python: 
    - python3: 

[Simonr]

Hi

I had a session last afternoon with testing, as well as ~2 hours this morning, and I still have not been able to recreate the white screen error by just letting the nRF52840 DK run in the Bluetooth Low Energy app. I guess we'll have to wait for a reply from the developers as I'm out of ideas on how to recreate the issue you're having, other than maybe rebooting your computer completely, to see if that helps, as my guess is that there are some conflicting files on the computer causing this. Can you post the revision and build date of your Dongle and DK (numbers below PCA1005X)?

Here's the log from this morning, where I tried letting the DK scan, connect, and advertise for some time to see if that triggered it.

08:15:51.399	Validating connectivity firmware for device with serial number 000683194832...
08:15:52.395	Connectivity firmware is valid.
08:15:52.395	Getting information from J-Link debugger...
08:15:53.883	Found device type: unknown. J-Link firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 7 2019 14:07:15.
08:15:53.884	Connectivity firmware version: 4.1.1. SoftDevice API version: 3. Baud rate: 1000000.
08:15:53.884	Opening adapter connected to COM13
08:15:54.803	Successfully opened COM13. Baud rate: 1000000. Flow control: none. Parity: none.
08:15:54.804	Reset performed on adapter COM13
08:15:55.925	Adapter connected to COM13 opened
08:15:58.837	Scan started
08:16:05.353	Connecting to device
08:16:05.821	Connected to device CD:3D:F1:F2:0C:E0
08:16:06.795	Attribute value read, handle: 0x03, value (0x): 4E-6F-72-64-69-63-5F-42-6C-69-6E-6B-79
08:16:25.545	Connection parameters updated for device CD:3D:F1:F2:0C:E0: interval 100ms, timeout 4000ms, latency: 0
08:24:48.459	Disconnected from device CD:3D:F1:F2:0C:E0, reason: BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION
09:03:19.225	Scan started
09:03:27.742	Connecting to device
09:03:28.071	Connected to device CD:3D:F1:F2:0C:E0
09:03:29.023	Attribute value read, handle: 0x03, value (0x): 4E-6F-72-64-69-63-5F-42-6C-69-6E-6B-79
09:03:47.934	Connection parameters updated for device CD:3D:F1:F2:0C:E0: interval 100ms, timeout 4000ms, latency: 0
10:05:58.163	Disconnected from device CD:3D:F1:F2:0C:E0, reason: BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION
10:06:33.387	Advertising started
10:23:13.089	Advertising stopped

Best regards,

Simon

[rodims]

Hi, 
I did not have the time some weeks ago to investigate this in depth due to development priorities. Nevertheless the nrfConnect, here "BlueTooth Low Energy" app is near to unusable for me. 

I spent a lot of time to narrow the conditions for this problem, but it is highly unreproducible. 
First to your questions:  
I don't think it makes sense that you run the application on your PC for testing, if you didn't experience a problem so far. As I already said I don't expect everybody to have this problem, otherwise it would have been handled and fixed already. So yes, the problem for some reason likes to appear on my PC very often, and if you never got any report from other users, you can only try to analyze the feedback which I can give you now. 
I'm quite sure that the real problem is a bug inside the nrfConnect applications / framework, so the question remains, why only I am suffering from it. 
Also as a side note, I'm currently testing with nRF Connect v3.3.0, but I have the problems with all previous versions since at least 1 year. 

1.) as said the problem may appear within seconds after starting e.g. the BlueTooth Low Energy app, or it may work for e.g. 30 minutes. However in average (number of starts versa running time without problem) it will be dead after lets say 5 minutes.  This makes it more or less impossible to do a real work with the tool. 

2. You asked for the dates of the Dongle PCA10059 and DKs.   As I said the problem appears with both, so it is unlikely a problem of a certain firmware revision. Especially after many many tests I can say that the problem even appears, if I do not select a device in the Bluetooth Low Energy App.  

I have other observations here.  The problem is not only related to the "Bluetooth Low Energy" app.  It's also present with the other apps. Namely the "Programmer" app also shows the problem. If I start both of them, AND after some time the problem appears, then BOTH applications windows are WHITE and empty. At exactly the same event time, whatever this event is.  

On my home PC could enforce the problem by sending the Desktop PC into sleep mode and wake it up again (this did not work on my Office PC though).  Afterwards the window content was white. 

In general I conclude that the problem is more related to the framework of the nrfConnect applications. Note that the starter application (where you start the apps) never is included in these problems. 

3) I tried a lot to find out whether the problem is related to the PC USB framework / stack, but I could not find an indication that USB is the source of the problem. Indeed when the problem appears, there is a sound played on the PC speaker, which sounds like my USB disconnect sound, however with several tools I verified that the "Bluetooth Low Energy" Sniffer device is always and stays connected. So the sound may come up due to some other Windows event. 

I also removed all of my other USB devices with the exception of e.g. my mouse to avoid any interaction between them. 
The problem also appears without all that devices. 

4)
So I investigated the problem from another side, the process view. I used Sysinternals Process Explorer, but the normal windows task manager should do the same. 

I found out that starting the nRFConnect v3.3.0 starts two sub processes as seen here, while starting "Bluetooth Low Energy starts the 3rd one (here selected with the tooltip showing the command line parameters used by the nrfConnect parent process. 

So if now the problem appears I can see that the process related to the "Bluetooth Low Energy" app also disappears, i.e. it is killed, or more precisely "the process simply crashes".  
For some reason the framework will leave the empty white window on the screen, but obviously the framework uses the window only as a container for the real app process. 

With that knowledge I started a visual Studio debugger for the running "Bluetooth Low Energy" process. When it crashes the Debugger will stop and show an assembly statement where the process crashed. However I have no meaningful PDB symbol files for this crash, which is an access violation, so thats the point where I stop investigation.  

Here is the Debugger output which is shown (reproducible) for this crash. 

The first lines as text: 

Exception thrown at 0x7B228E80 (af7bbb4e-3469-4df4-a8b9-18bca6b26dbb.tmp.node) in nRF Connect.exe: 0xC0000005: Access violation reading location 0x096F9000.

The debugger also would like to load a symbol file usb_bindings.pdb, but I cannot find something like this anywhere, so I suspect this is NOT a windows DLL, but something related to the nrfConnect application. 

So that's something you could forward to your developers. 
This does not yet answer the questions, what is the reason on my PC which lets the application so often run into this not properly handled condition and crash, but that's a starting point. 

I still need this application urgently and would be happy to be able to use more than 5 minutes and then having to restart everything.  

[Simonr]

Hi

Thank you so much for this thorough report I'm sorry that we haven't been able to give you an update on what is happening here, but the devs are struggling to find the reason for these crashes as well. Hopefully, the information you've provided will help them and hurry up the process so that you'll be able to run the nRFConnect apps as intended.

Best regards,

Simon

[rodims]

After a long time of pain I found out, what caused the problem in the first place. 
In  previous tests last year I already removed all other USB devices from the USB bus (with the exception of the mouse), including external hubs. Now it turns out that my the Logitech mouse (10 years old) is irregularly causing this problem. Not using an external hub.  I replaced it with a simple Microsoft Mouse and the problem has not been seen again since several days now. 

Lets assume that the mouse (or in combinations with its driver) has some damage which causes some non-standard usb packets in the usb system. The mouse likely was not on the same internal or external hub as the devices which I used for nRF Connect "Bluetooth Low Energy" app  in all my tests. 

So it's still some problem with the nrfConnect tools, which likely listen to all (USB Bluetooth) devices attaching and detaching from the bus, and which crash in these special (non-reproducible) situations. The result of this crash then was the empty white client area of the window. That's what I analyzed so far last year.  

I didn't have to touch or move the old mouse for the problem to occur, but it also happened occasionally when I moved the mouse. 

So while this (assumed) bug is still present in the nrfConnect framework, this case can be closed, at least for me. 

[Simonr]

Hi

First of all, I want to apologize sincerely. It seems like this case fell through the cracks, as it hasn't been any updates on the case internally. I am so sorry about this, as this shouldn't happen.

On the other hand, I'm really glad that you were able to figure it out on your own, and I want to thank you for sharing your solution with us. I have reported this internally, and we will hopefully find a fix to implement in a future nRFConnect release.

Best regards,

Simon