[SOLVED] WDF_VIOLATION error when monitoring Serial prints on PC

Troubleshooting
1

Hi all,
Well, I was hoping to find this as a common problem… no luck there. Anyway, I am using particle dev and using debug prints. I am frequently getting this WDF violation pale blue screen of death. Other micros (variety of Arduinos, spark(?)) don’t have this problem. Is there anything special about the photon driver? is it updated frequently? I also haven’t been able to find any windows logs that might provide more details on the crash but no joy there so far.

thanks for any insights.

1 Like
2

Yeah, just started seeing this today.

I’m on Windows 10 insider if that makes a difference.

3

Yeah I get this about once a day on W10 as well. Generally happens if I print to serial without any delay in between.

4

I’m always seeing it when I close Putty. On an earlier build of Windows 10 it would freeze the system until I unplugged the USB. I couldn’t type or move the mouse cursor.

5

ah, good point… I will try to limit my prints. slowing down to 9600baud seems to help.
thanks.

6

interesting… so that kind of points to the usb/serial driver doesn’t it?

7

anybody still seeing this issue, is there a fix?

8

Been ok for me… I kind of correlated it to messing with the serial monitor while the photon is resetting (and the photon device drops out in windows). Can’t prove it though.

9

Not sure what I changed but I’m getting a blue screen just about every time disconnect serial when I’m going to re-flash the photon.

10

Hi,

OK so I also just started to see this problem :-((. Seems to be when using Serial (as opposed to Serial1). I normally use Serial1 as it doesn’t lose connection after a reboot - thus making life far simpler ;-).

Just starting a new app which needs a serial port - so went back to trying to use Serial, and it bombed within minutes. Failed to connect, then when pressing this button again Blue-Screens :-((. All from Atom Dev…

Not had a BlueScreen on Win10 before this :-O. The issue certainly does NOT exist on using a serial port with its own (FTDI) driver so I suspect the Photon USB driver is at fault :-((.

Looks like I won’t be using Serial again for a while then :-((.

Graham

11

Have you got some test code that exhibits this, as I can’t get my Win 8.1 or 10 to crash this way?

12

Hi - again ;-),

Not really any test code - as it dies when I enable the serial monitor (in the dev environment), then click on connect/disconnect. Its not actually doing anything at that time :open_mouth: - although you are welcome to the current code - its a new startup project anyway so has hardly any code in it :-O. I started with the ino file from my MUCH bigger app, and removed a shed-load of code leaving a basic shell.

I really don’t ‘think’ its anything to do with my code :-O.

The serial monitor doesn’t disconnect itself if you press reset, so press to disconnect, then connect and BOOM.

I really can’t try it again for a while as the PC is also doing some simple serial 3D printing on another serial port. Each print takes about 1 1/4 hours, and the dev problem completely ruined a print run :-(( - so I can’t (yet) risk doing it again…

I will attach my code in case it does make any difference though…

Well - I would if I was allowed to - blocks a zip file :-((.

Many thanks again

BR

Graham

13

Could you try a different serial monitor like PuTTY (which I use) to see if it’s a driver and not a Dev problem?

What version Dev and Node are you using?
Does particle serial monitor exhibit the same thing?

14

I have the same issue from Dev, Putty and RealTerm. It only happens when printing lots to serial. Putting a 100ms delay between print statements stops the issue from happening

15

OK, I’ve now tested with this code and can’t still make it crash

#define no_AUTO_

#ifdef _AUTO_
SYSTEM_MODE(AUTOMATIC)
#else
SYSTEM_MODE(MANUAL)
#endif

char txt[65] = "123456789112345678921234567893123456789412345678951234567896123";
void setup()
{
    Serial.begin(115200);
#ifdef _AUTO
    Particle.function("test", test);
#endif
}

uint32_t ms;
void loop()
{
    while(1)
    {
#ifdef _AUTO_
        if (millis() - ms >= 9000)
        {
            Particle.process();
            ms = millis();
        }
#endif
    Serial.print(txt);
    }
}

#ifdef _AUTO_
int test(String cmd)
{
    cmd.toCharArray(txt, 65);
    return strlen(txt);
}
#endif

In MANUAL mode this should flood the Serial port quite a bit, but I’m not trying to overflow the TX buffer (64 byte).

The only thing I did achieve was to crash Dev, but that seems to be due to an overflow of the Serial Monitor buffer, when not clearing the output from time to time.

16

The 0.5.0 branch includes fixes to the USB driver which should bring increased stability. If you are building locally, take it for a spin!

1 Like
17

no help for me… I have been avoiding this problem by removing all serial prints, but now I need them again and it seems even worse than before! I am on windows 10, using the visual micro addon serial monitor or putty with same results.

anybody know why serial1 might be better?
haven’t tried that yet. it has t be a driver issue, I just don’t know who to go for for that driver.

18

Any progress on this topic ?

It looks to me a Windows driver problem. Has anyone investigated that ?

I’m using Photon with FW v0.6.0 on Windows 10 version 1607.
The issue is rather annoying because it triggers Windows BSOD when it occurs.

19

Have you removed all Particle Serial Drivers (even on non-present devices - also tick the “Remove from harddrive” checkbox if present) and then “reinstalled” them?

I have done that and have no issue with any of my Windows machines (8.1 Pro 32 & 64, 10 Pro 32 & 64)

You could also try installing the Particle drivers (although non required on 10)

1 Like
20

Hi @ScruffR,
thank you so much for your prompt reply and advices !

I had installed an old version of Particle Serial port driver. I have been trying to reproduce the issue again after having followed your advices and I can confirm that the issue is definitely sorted out ! :sunglasses:
The Virtual COM port now works like a charm.

It was enough to uninstall and remove the old driver and let Windows 10 install its standard VCOM over USB driver.

It now probably worth adding the [SOLVED] keyword to the name of this thread.

3 Likes