mscomm

Hi to everyone,
I wrote a software that sends strings to a servo-motor via COMM port while pressing arrow keys.
The movement starts on keydown event and should stop on keyup event.
The problem is that sometimes the software hangs after a keydown string and this prevents from receiving keyup string and going on.
Can anyone find out the bug in this code that causes this problem?
Thanks for your attention.

Code:

---

Private Sub Form_Load()
    MSComm2.CommPort = Combo4.ListIndex
' speed 9600, no parity, 8 data bit  and 1 stop bit
    MSComm2.settings = "9600,N,8,1"
    MSComm2.InBufferSize = 1024
' open port
    MSComm2.PortOpen = True
End Sub


Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)

If KeyCode <> KeyCode1 Then
    KeyCode1 = KeyCode
    Stringa = ""
    Select Case KeyCode

        Case vbKeyLeft And Shift = 1
            Stringa = "#:Me#"
             
        Case vbKeyRight And Shift = 1
            Stringa = "#:Mw#"

        Case vbKeyUp And Shift = 1
            Stringa = "#:Ms#"
               
        Case vbKeyDown And Shift = 1
            Stringa = "#:Mn#"
    Case Else
       
    End Select

    If Stringa <> "" And MSComm2.PortOpen Then
        MSComm2.Output = Stringa
        TastoPremuto = True
    End If
End If
End Sub


Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)

If TastoPremuto Then
If MSComm2.PortOpen Then
    MSComm2.Output = "#:Q#"
End If
KeyCode1 = 0
TastoPremuto = False
End If
End Sub

---

It sounds as though you're banging data out of the serial port for as long as the key is down. This shouldn't be a problem but you're not actually looking at the output buffer to see if the next packet of data will fit or whether the buffer is full.

It looks as though the output buffer is filling up so that even when you lift the key there's still a ton of data waiting in the outbuffer which will take time to send. The MSCOmm control is not very good at full duplex comms so don't expect to receive much while it's still busy sending.

Apart from that the MSComm has an undocumented bug - well, it's not actually a bug in MSComm, it's more of a bug in windows NT that has continued through all NT derivative `Operating systems (W2000, XP, Vista etc.)

Not saying this is your problem but it kind of sounds like it.

The MSComm properties basically boil down to api functions. For example MSComm1.Output calls the API writefile function. (I know it's not a file but windows treats the com ports as files)

If an application calls the 'WriteFile' function to queue data into the com port driver's TX buffer then if the buffer still contains data from a previous send AND depending on the state of the underlying com timeouts the WriteFile function does not return until all the data has cleared the buffer and in some cases the function never returns causing the application to hang.

Using OverlappedIO this shouldn't happen but it does. I don't think the MSComm control is correctly implementing overlappedIO

The way to avoid it is.

Send one packet of data but don't send the next packet until the first packet has been sent completely.

You ought to be able to check the OutBufferCount to see if your data will fit into the OutBuffer but because of the above mentioned 'feature' you should not try to queue more data until the outbuffercount is zero.
So, to summarize - before sending data check the OutBufferCount and only send the next bit of data when outbuffercount is zero.

Adding to IanS's statements, the OnComm event will automatically fire on these two events, and many more. Your Object Browser will give you a full description of all the MSComm properties, events, etc.

Curious, what Pic are you using?

Code:

---

Case comEventTxFull  ' Transmit buffer full.
Case comEvSend  ' There are SThreshold number of characters in the transmit buffer.

---

Hi Ians,
it should be something regarding COM data buffer, as you said, even if the if-clause "if keycode<>keycode1", where keycode1 is last key used, prevents the software from sending multiple strings while key being pressed.
I'm looking for a way to use OutBufferCount property to solve the problem as you suggested.

Thank you for the info, CDRIVE, the pic is in my rajiva-modified-heq5 telescope mount that I'm trying to control!

Quote:

---

Originally Posted by andreaconsole

Thank you for the info, CDRIVE, the pic is in my rajiva-modified-heq5 telescope mount that I'm trying to control!

---

Sounds like a user friendly telescope, as it accepts String data and not forcing you or MSComm to deal with Binary & Hex!

I tried this code before mscomm2.output lines

Code:

---

While MSComm2.OutBufferCount <> 0
      Sleep 100
      DoEvents
Wend

---

but the problem is that after the buffer reaches overflow for the first time, the following strings are sent (although buffer gets empty very slowly), but they are not processed anymore by the pic.

Quote:

---

Originally Posted by CDRIVE

Sounds like a user friendly telescope, as it accepts String data and not forcing you or MSComm to deal with Binary & Hex!

---

it's called LX200 standard, and it's luckily quite common ;)

As CDDrive said you ought to be looking at some way to incorporate the OnComm event.

But, just making quick changes to your existing code - Don't bother waiting in a loop. All I'd do is in the KeyDown sub just add a line right at the top so it's the first thing that happens check the OutBufferCount. If it's greater than zero then simply exit sub without trying to queue another packet.

That will have two effects.

1 - It'll prevent a buffer overflow - the keyDown events will be coming faster than the com port can send data so piling more data into the buffer will cause an overflow.

2 - It'll reduce the amount of data in the outbuffer at any one time so as soon as you lift your finger off the button the motor will stop moving. If you pile a lot of data into the outbuffer it will keep the motor moving long after you lift up your finger. People using machinery like that would like the motor to stop as soon as you lift your finger. You'll achieve that by simply exiting the KeyDown sub if the previous packet is still in transit.

Have you tried something like this at the top of your KeyDown event? I didn't test this though.

Code:

---



Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
  If MSComm1.CommEvent = comEventTxFull Then Exit Sub
End Sub

---

You could also try something like this.. but I didn't test it either.

Code:

---



Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
  If MSComm1.OutBufferCount <> 0 Then Exit Sub   
End Sub

---

Edit: OutBufferCount code changed from 510 to <> 0 to prevent telescope movement after the key is released, as per Ians' suggestion in post 7.

Quote:

---

Originally Posted by IanS

As CDDrive said you ought to be looking at some way to incorporate the OnComm event.

But, just making quick changes to your existing code - Don't bother waiting in a loop. All I'd do is in the KeyDown sub just add a line right at the top so it's the first thing that happens check the OutBufferCount. If it's greater than zero then simply exit sub without trying to queue another packet.

That will have two effects.

1 - It'll prevent a buffer overflow - the keyDown events will be coming faster than the com port can send data so piling more data into the buffer will cause an overflow.

2 - It'll reduce the amount of data in the outbuffer at any one time so as soon as you lift your finger off the button the motor will stop moving. If you pile a lot of data into the outbuffer it will keep the motor moving long after you lift up your finger. People using machinery like that would like the motor to stop as soon as you lift your finger. You'll achieve that by simply exiting the KeyDown sub if the previous packet is still in transit.

---

You made some interesting points (regarding OutBufferCount) that I failed to foresee and he should modify my OutBufferCount code to <> 0. :thumb:

the sub send exactly one string when the finger presses the key (look at global keycode1 var), independentely from the time the key being pressed. So, if I put a OutBufferCount if-clause before the key-down or key-up event, the motor simply will not receive the related string (and for example the motor should keep moving forever without a "stop" string).
However, after further tests, I found that the problem seems to be that usb-com converter I use crashes (I have to re-plug it) if strings sent are too close. I'll try to put a delay between commands and verify if it solves the problem!

in addition:

this code:

Code:

---

Private Sub MSComm2_OnComm()
Text18.Text = MSComm2.CommEvent
End Sub

---

never write anything in text18, even if the communication between pc and telescope mount hangs... How is it possible?

edit:

no buffer overflow: buffer (set 1024 bytes) never exceed 4 or 5 bytes (one string lenght!).
The mount does not supports any handshaking mode (CTSholding & DSRholding always false)

When the communication begins to fault, the buffer retains last string sent for few seconds and then gets empty , but the mount never process it. Where is the problem? Can anyone guess?

Quote:

---

Originally Posted by andreaconsole

in addition:

this code:

Code:

---

Private Sub MSComm2_OnComm()
Text18.Text = MSComm2.CommEvent
End Sub

---

never write anything in text18, even if the communication between pc and telescope mount hangs... How is it possible?

---

This should look like this which prints everything:

Code:

---

Private Sub MSComm2_OnComm()
Text18.Text = Text18.Text & MSComm2.Input
End Sub

---

Better yet, it should look like this though. Errors and other CommEvents are filtered.

Code:

---

Private Sub MSComm2_OnComm()
    If MSComm1.CommEvent = comEvReceive Then
      Text18.Text = Text18.Text & MSComm2.Input
    End If
End Sub

---

Quote:

---

Originally Posted by andreaconsole

edit:

no buffer overflow: buffer (set 1024 bytes) never exceed 4 or 5 bytes (one string lenght!).
The mount does not supports any handshaking mode (CTSholding & DSRholding always false)

When the communication begins to fault, the buffer retains last string sent for few seconds and then gets empty , but the mount never process it. Where is the problem? Can anyone guess?

---

In the old days, prior to handshaking, the Break command was used to halt transmission by putting the TX line in a Mark (High) state and holding it there until commanded to do otherwise. Many Microcontroller based devices still use the Break command though. Your Telescope may require it. This is only one possibility.

Another possibility: Your Telescope probably doesn't make use of the RS232 Control lines, therefore you must select Software Handshaking. Did you?

Bad news: Some of the USB/Serial converters on the market don't support the Break command. So if your Telescope requires it your converter must be able to pass it. The Belkin model FSU409 is one of the models that won't pass it. You can test the Break command with a LoopBack tester, Resistor & LED, or a Voltmeter.

Btw, I noticed that you're using MSComm2. Do you have more than one CommControl on your form?

Your code doesn't print anything either, unfortunately...
It seems there are not comm errors, must be something else...

LX200 protocol, that specifies the strings, doesn't seem to allow handshaking, boh!

Yes, I have two mscomm controls, but I'm using just one at the moment

Quote:

---

Originally Posted by andreaconsole

Your code doesn't print anything either, unfortunately...

---

Did you set RThreshold = 1 in the MSComm properties? If it's set to 0 it will never fire! You can also set it in the Form_Load event.

Code:

---

MSComm1.RThreshold = 1
MSComm2.RThreshold = 1

---

Quote:

---

Originally Posted by andreaconsole

LX200 protocol, that specifies the strings, doesn't seem to allow handshaking, boh!

---

Is there an on-line manual for it? I'll read it if there is. If not, do you have an html or pdf version? You can upload it here as an attachment.

Hi CDRIVE, thank you very much for your support. Attached you'll find lx200 command list, just to understand what I'm talking about.
To summarize the problem:
I have a mount which processes string commands got from its serial port
I have a USB to COM converter to connect the mount to the PC

After a few commands, the mount stop processing the strings and:
there is no buffer overload
there is no comm_event raise

if I replug the USB to COM converter and reopen the COM port, it works again.

I cannot open the PDF, but... I suspect (without evidence) that there may be a timing issue. What I'd suggest is that you change your code a little bit. Do everything in the KeyUp event, so that you don't pass the TastoPremuto flag around (this may be the problem, though nothing is really obvious). For example,

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
If KeyCode <> KeyCode1 Then
KeyCode1 = KeyCode
Stringa = ""
Select Case KeyCode

Case vbKeyLeft And Shift = 1
Stringa = "#:Me#"

Case vbKeyRight And Shift = 1
Stringa = "#:Mw#"

Case vbKeyUp And Shift = 1
Stringa = "#:Ms#"

Case vbKeyDown And Shift = 1
Stringa = "#:Mn#"
Case Else

End Select

If Stringa <> "" And MSComm2.PortOpen Then
MSComm2.Output = Stringa
'you can add a call to a delay routine here, if needed.
MSComm2.Output = "#:Q#"
End If
End If
KeyCode1 = 0
End Sub

Dick

Sorry about the lack of formatting, this was just "cut and paste."

thank you for your suggestion, but I can't put everything in the keyup event since I need to keep the movement while key is down and stop it when key goes up. (Could it be a problem with keyboard buffer?? How to resolve if it's the case?? :eek:)
However I'm trying to add a delay as you suggested, I'll make you know if it works!

Hi,

If you need to keep it "moving" while the key is down, I think you need to use the keypress event -- keydown does not repeat, while keypress does. You'd decode the Keyascii parameter, instead of the Keycode parameter

Alternately, you might use a CommandButton for each movement (start and stop a timer, with the timer Interval determining the rate), and then send the command to complete the movement later. However, your design may be fine -- I'm am worried about timing, just because I've seen trouble in that area before.

I'd say that the Keyup event should never start before the Keydown event ends -- though the MSComm Output method may take enough time that the flag that you are setting (TastoPremuto = True) is tested in the Keyup event before it has been set in the Keydown event. So, perhaps all you need to do is to move TastoPremuto = True to before the MSComm2.Output = Stringa statement, instead of after.

These sorts of things tend to require "hands on," so keep trying different variations.

Dick

It has just become obvious to me that I've not been paying close enough attention to your code. All of your code is one way (TX) with no provisions for Input (RX) from the Microcontroller. The problem is most likely an overflow of the Micro's Input Buffer. Read the second paragraph in your instruction manual where it explains what the Micro sends back to the PC if it's unable to execute a command.

You need to be looking for this NAK in OnComm (comEvReceive) event and take appropriate action when received.

First of all I thank all of you very much for your help!
Unfortunately, none of your suggestion worked:
1-keypressed event, as well as keydown event, repeats until the key is pressed. I don't need this (since the string sent to the mount make it move until it receive the "stop" string), but I resolved by using the var keycode1.
2-it don't seem to be a problem of keyboard buffer since I made experiments without COM port and it didn't have any problem
3-NAK is not a standard for all mounts: in particular my mount never sayd anything in mscomm_event
4-the fact that I reset the problem by replugging the usb-to-com-converter, makes me think that the converter could be the problem, perphaps its buffer...
5-Even moving tastopremuto=true before mscomm.output, nothing changes.

My code now is a bit different: I added a timer to prevent string sent to be too close, but the problem remain.

Code:

---

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If Shift = 1 Then
        If KeyCode <> KeyCode1 Then
            KeyCode1 = KeyCode
            Select Case KeyCode
                'AR commands
                Case vbKeyLeft
                    Stringa = "#:Me#"                     
                Case vbKeyRight
                    Stringa = "#:Mw#"
       
                'DEC commands
                Case vbKeyUp
                    Stringa = "#:Ms#"     
                Case vbKeyDown
                    Stringa = "#:Mn#"
            Case Else
                Stringa = ""
            End Select
            If Stringa <> "" Then TastoPremuto = True
        End If
    End If
End Sub


Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
If TastoPremuto Then
    Stringa = "#:Q#"
    KeyCode1 = 0
    TastoPremuto = False
End If
End Sub

Private Sub Timer3_Timer() '200ms
If MSComm2.PortOpen Then
    While MSComm2.OutBufferCount <> 0
        Sleep 100
        DoEvents
    Wend
    If Stringa <> Stringa1 And Stringa <> "" Then
        Stringa1 = Stringa
        If MSComm2.PortOpen Then MSComm2.Output = Stringa
        Beep
    End If
End If
End Sub

---

Realize that you will not see the NAK in the OnComm event, unless you set MSComm2.RThreshold = 1. Have you done that?

Generally, I don't use OnComm event processing to look for a NAK. Instead, I use a polling method. Just as an example,

Public Declare Function timeGetTime Lib "winmm.dll" () As Long

Public Function WaitForNAK(ByVal milliseconds As Long)
Dim Timeout As Long
Dim NAKReceived As Boolean
Dim Buffer As String
Timeout = timeGetTime + milliseconds
Do Until timeGetTime > Timeout
If MSComm2.InBufferCount > 0 Then
Buffer = MSComm2.Input
If InStr(Buffer, Chr$(21)) Then
NAKReceived = True
End If
End If
Loop
WaitForNAK = NAKReceived
End Function

I'd call this function after sending a command (specify the number of mS that you want to wait for a NAK reply). It will return True if the controller sent a NAK, and False, if no NAK was received. If a NAK was received, then wait and try again.

Dick

I told him about RThreshold back in post 16.

Well, sometimes oncomm event fires, and the input is #E03#: it looks like an error, but it's not listed in the documentation I found online. However, when I receive this message (that is the one the mount put out, and not every time it hangs), it's too late to do anything because it simply stops working. I think my mount does not have NAK (it's not for all mounts, only the newer), so the code to handle it didn't work for me. By now my solution is to put a delay between commands, it seems to me that I can't do anything better...
Thank you again for your suggestions!

If you think that's the problem then move your TX code to a Timer and send it out every 500mS or so and work your way down until it freezes again. I will hang with you until you get it working. ;)

Reading quickly back through all these posts my understanding is that yu only need to send one START command when the key is pressed and then one STOP command when the key is released.

If you hold the key down then that would continue to generate keydown events for as long as the key is down which will of course keep sending start commands all of which will be queued up in the tx buffer which would take some time to be sent even after you've lifted the key.

You need to have a global boolean variable - maybe call it MotorRunning

In the keydown event send the start command out of the serial port and then set MotorRunning to True. Now each time the keydown event is occurs you check the variable, if it's true you simply exit without sending another start command.

In the KeyUp event you send the stop command and set MotorRunning=False

By using the variable you only send the start command once as the key is pressed and the stop command once when the key is lifted.

Hi IanS, I already achieve what you said using the global variable keycode1. The program will send commands only if the new keycode value is different from stored keycode1 value!

Andrea, I'm going to cover a number of things here, some of which I may have missed in your previous posts. If I did then I apologize for repeating it.

(1) We've never seen all of your code. We have no idea what your MSComm.Settings are, so we don't know if they match what your mount requires.

(2) I seriously doubt that your problem is in the USB/Serial converter, but if you want to test it on its own merits then short the TX pin to the RX pin and input the data directly back to your app.

(3) You're using the Sleep API in your code. Don't do it! Sleep is an awful API. I've discovered (from the Gurus here at VBForums) that the WaitMessage API is a far better alternative. That said, it would be preferable to move code (that requires a delay) into a Timer event instead.

(4) I see no reason to repeatedly check the PortOpen property as you're doing. You can test this property in the Form_Load and open it there. You can then test it again and close it in the Form's QueryUnload event. While we're on the subject here's a little known tip... The following code does not physically check the status of the port.

Code:

---

Private Sub Form_Load()
  MSComm1.CommPort = 1
      If MSComm1.PortOpen = True Then
        MsgBox "COM 1 Is In Use!"
      Else
        MsgBox "COM 1 Is Alvailable For Use."
      End If
End Sub

---

What it's really testing is whether it was set to True or False somewhere else in your program. To restate.. If you opened COM 1 in Hyperterminal the above code would return False. That's why error trapping is a must when deploying your app to others that may have other apps using the same CommPort.

(5) Finally, I would change your Timer code from this..

Code:

---

Private Sub Timer3_Timer() '200ms
If MSComm2.PortOpen Then
    While MSComm2.OutBufferCount <> 0
        Sleep 100
        DoEvents
    Wend
    If Stringa <> Stringa1 And Stringa <> "" Then
        Stringa1 = Stringa
        If MSComm2.PortOpen Then MSComm2.Output = Stringa
        Beep
    End If
End If
End Sub

---

to something like this.

Code:

---

Private Sub Timer3_Timer() '200ms
  If MSComm2.OutBufferCount <> 0 Then
      Exit Sub
  Else
      If Stringa <> Stringa1 And Stringa <> "" Then
        Stringa1 = Stringa
        MSComm2.Output = Stringa
        Beep
      End If
  End If
End Sub

---

(1)
You did not see my code because it's about one thousand lines long :D

Code:

---

    MSComm2.CommPort = Combo4.ListIndex
' speed 9600, no parity, 8 data bit  and 1 stop bit
    MSComm2.settings = "9600,N,8,1"
    MSComm2.InBufferSize = 1024
' open port
    MSComm2.PortOpen = True

---

(2) This is a test I will do if the problem becomes too annoying, thanks!
(3) I used sleep just as a test. This is last version of code that I'm going to test:

Code:

---

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If Shift = 1 Then
    If KeyCode <> KeyCode1 And KeyUpTime <> Now And KeyCode <> 16 Then
        KeyCode1 = KeyCode
        TastoPremuto = True
        Select Case KeyCode
            'AR commands
            Case vbKeyLeft
                If Check7.Value = 0 Then Stringa = "#:Mw#" Else Stringa = "#:Me#"
            Case vbKeyRight
                If Check7.Value = 0 Then Stringa = "#:Me#" Else Stringa = "#:Mw#"
            'DEC commands
            Case vbKeyUp
                If Check8.Value = 0 Then Stringa = "#:Mn#" Else Stringa = "#:Ms#"
            Case vbKeyDown
                If Check8.Value = 0 Then Stringa = "#:Ms#" Else Stringa = "#:Mn#"
            Case Else
                Stringa = ""
                TastoPremuto = False
        End Select
        If MSComm2.PortOpen And Stringa <> "" Then MSComm2.Output = Stringa
        If Not m_scope Is Nothing Then
            Select Case Stringa
            Case "#:Mw#"
                m_scope.MoveAxis 0, Val(Combo6.Text)
            Case "#:Me#"
                m_scope.MoveAxis 0, -Val(Combo6.Text)
            Case "#:Mn#"
                m_scope.MoveAxis 1, Val(Combo7.Text)
            Case "#:Ms#"
                m_scope.MoveAxis 1, -Val(Combo7.Text)
            End Select
        End If
        Shape6.FillColor = &HFF&
    End If
End If
End Sub

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
If TastoPremuto Then
    Stringa = "#:Q#"
    If MSComm2.PortOpen Then MSComm2.Output = Stringa
    If Not m_scope Is Nothing Then
        m_scope.MoveAxis 0, 0
        m_scope.MoveAxis 1, 0
    End If
    Shape6.FillColor = &H80&
    KeyCode1 = 0
    TastoPremuto = False
    KeyUpTime = Now
End If
End Sub

---

I know there are a lot of lines you can not understand because the program is far more complex...

(4) I don't use "portopen" property to check the mscomm: the software can control the mount in two ways, or through serial port, or through a particular interface called ASCOM (it's a software architecture). By checking the portopen property I understand the mode selected.

Thank you for your support, I'm trying to use the software in real situations without stressing it by now, in order to undertand if I can simply ignore the problem.

Quote:

---

andreaconsole:
(4) I don't use "portopen" property to check the mscomm:

---

Yes you do. You prefaced most commands to MSComm with..

Code:

---

If MSComm1.PortOpen = True Then

---

That is checking the status of the port.

yes I do, but as I said, I use this check as a flag to know if, on e.g. keydown event, the command must reach the mount via serial port or via ASCOM drive, because the user can always change the way to communicate with the mount

(PS 2584 lines, plus 450 lines in modules)

I think that it should have become obvious by now that your issue is RX Buffer overflow in your Micro. The preferred method of any type of serial communication is some form of protocol that can tell the transmitter when it can send or when it must wait. Since you know your scope better any of us it's incumbent upon you to find a return that you can use. If you can't, or there is none, then your only alternative is to slow down your output data by using a timer. On the other hand, if your Micro can handle a slower Bit read rate you won't have to use a Timer or change any other code.

Regarding your suspicions with the USB converter: When the scope freezes you said that a replug clears the problem. Which end of the converter are you unplugging? If it's the USB end then try a replug with the RS232 end and post your results.

Quote:

---

Originally Posted by andreaconsole

yes I do, but as I said, I use this check as a flag to know if, on e.g. keydown event, the command must reach the mount via serial port or via ASCOM drive, because the user can always change the way to communicate with the mount

---

Is this change done from within your app?

Quote:

---

Originally Posted by CDRIVE

Is this change done from within your app?

---

yes, it is

Quote:

---

Originally Posted by andreaconsole

yes, it is

---

OK, then that makes sense. I just wanted to make sure that you understood what I said back in post # 31. On the other hand, if you're planning to deploy this app many comm code blocks should include judicious error trapping. The following properties should all have error traps.

.PortOpen
.Output
.Break
.Settings ' this one's debatable though

Here's a diagnostic utility (Portmon.exe) that you can use to trouble shoot your port. I've used it many times. It must be running and port selected prior to opening a port. This app will read Hex as well as ASCII.

http://technet.microsoft.com/en-us/s.../bb896644.aspx

If your USB/Serial converter is the culprit you should see it happen with Portmon.

Perfect! Now I have a lot of tools to face the issue ;)