BUG Report - COM-Port over CDC (usbser) RRS feed

  • Question

  • explanation:

    goal - to receive binary data of 20992 bytes from usb-device enumerated as cdc virtual com-port


    1 - send command to device to start transmission of data block (20992 bytes)

    2 - receive this block (any binary terminal application)


    result - we have received 20992 bytes (0000-51FF)

    but it is corrupted on addresses : 3ED1-3FFF

    data on addresses 0000-3ED0 and 4000-51FF is not corrupted


    the same device is working with built-in usbser-driver on all windows versions : XP, W7, W8

    but on W10 we got this problem...

    Have hope it can be fixed before w10 release

    • Moved by Brandon Records Tuesday, March 31, 2015 8:26 PM Moved to appropriate forum.
    Wednesday, March 18, 2015 11:12 PM

All replies

  • sorry for delay...

    today have installed HDD Device Monitoring Studio

    took logs on USB and COM

    - USB log data is correct

    - COM-port data is corrupted (the same way as described above)

    log files - htt_p://www.tiecar.net/downloads/CDC_BUG_HDD_logs.zip


    I do not understand why have i to ask the something?

    seems i have informed developers team about bug...

    may be i have sent report in wrong place...

    so just say me where is correct place for feedback messages...



    I have installed Windows 10 to the Oracle VM VirtualBox

    But this bug had been found by my customer... he uses real PC for Windows 10 testings


    Version language : English (USA)
          CompanyName : Microsoft Corporation
          FileDescription : USB Serial Driver
          FileVersion : 10.0.9926.0 (fbl_awesome1501.150119-1648)
          InternalName : usbser.sys
          LegalCopyright : © Microsoft Corporation. All rights reserved.
          OriginalFilename : usbser.sys
          ProductName : Microsoft® Windows® Operating System
          ProductVersion : 10.0.9926.0

    Creation Date : 20/03/2015  23:56:46
    Last Modif. Date : 20/01/2015  02:24:42
    Last Access Date : 20/03/2015  23:56:46
    FileSize : 47616 bytes ( 46.500 KB,  0.045 MB )
    FileVersionInfoSize : 1812 bytes 
    File type : Dynamic Link Library (0x2)
    Target OS : Win32 API (Windows NT) (0x40004)
    File/Product version : 10.0.9926.0 / 10.0.9926.0
    Language  : English (USA) (0x409)
    Character Set : 1200 (ANSI - Unicode (BMP of ISO 10646)) (0x4B0)

    Build Information :
    Debug Version : no
    Patched Version : no
    Prerelease Version : no
    Private Version : no
    Special Build : no

    • Edited by alodin_ua Friday, March 20, 2015 10:03 PM
    Friday, March 20, 2015 9:46 PM
  • i see...

    so what is decision?

    :-) i see real bug... and no way to inform ms about it... very strange :-)

    if they will not to fix this bug before release... they would to get many angry hw developers

    actually I fulfilled my mission... hope my message will be delivered to the interested people

    Friday, March 20, 2015 11:01 PM
  • Hi, We know this post is pretty old, but wondering if it is solved by any chance. For information, we are still experiencing the same issue with the windows10 1703 (15063.540)
    Monday, August 21, 2017 8:17 AM
  • How can you help to provide a repro? Does this problem reproduce with some common stock USB to serial adapter (Silicon Labs, FTDI) or it is custom?

    -- pa

    • Edited by Pavel A Monday, August 21, 2017 11:41 AM
    Monday, August 21, 2017 11:38 AM
  • Hi,

    This issue appears with our products while transmitting picture from a NXP's LPC4333JBD144 μC using a virtual COM port (i.e., USB CDC). The issue is observed only on Windows 10 and not on Windows 7.

    For reference the following are the pictures with the error in data read by the host application on a Windows 10 platform.

    On the received pictures, I can see 3 different patterns:

    • Black pattern
    • Random noise pattern
    • Shifted pattern

    To reproduce this issue, I created a sample project on LPCXpresso on the device side and a C# project on the host side.

    Device side:

    Project based on LPCOpen example 'lpcopen_2_19_lpcxpresso_ngx_xplorer_4330'. - When the μC receives char '0', it sends back the data size it will transmit (225792 for my example) as a UINT32 (4 bytes) - When the μC receives char '1', it sends back 225792 bytes by packet of 256 bytes each. Each 256 bytes follow this pattern: 0x00, 0x01, ... , 0xFF.

    Host side:

    Initially I developed the host application using .NET SerialPort object with the help of DataReceived event to receive the data from the COM port. With this I could easily simulate the issue with lots of errors while reading data. Then with the reference from various blogs (especially from http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport), I switched to method SerialPort.BaseStream. Then the issue seem to be less frequent, but still I could see issue rarely though.

    To detect an error, I count the number of times I receive the 256 byte pattern (0x00, 0x01, ...  ,0xFF) on a full reception. If it isn't equal to the expected number (..which is 225792 / 256 = 882), then I create a log with the error data into data.txt in the same directory. The conditions for a full reception is either receiving 225792 bytes or a timeout of 1 second.

    I have monitored the packet in the USB PHY using USB protocol suite (Teledyne Lecroy Mercury T2) and I didn't find any transmission error that is observed by the application.

    So I come to a conclusion that the issue seem to be very specific to Windows 10 + USB CDC while reading the data using SerialPort object.

    Source code for testing can be found here: https://github.com/AlecG74/cdc_com_test

    Tested on Windows 10 Professional 64bit version: 1703-15063.540

    Tuesday, August 22, 2017 3:12 PM
  • Based on the opinion on the .NET SerialPort class in the blog you've linked - the problem can be also related to the .NET libraries in Win10.  If you could make a small test that uses only the core win32 API, we would be more confident that the problem is in the USB CDC drivers.

    -- pa

    Tuesday, August 22, 2017 4:38 PM
  • We have created a win32 command line tool with a similar functionality.
    We could simulate the issue with it (but we need to wait for a long time as it is slower).

    Source code has been added to the same git location.

    Description of the win32 tool:

    In the win32 application, we have created a custom class named CSerialport which implements the serial port functions like open (), read () and write () using the CreateFile().

    This tool functions very similar to the .NET based application to use it with the target hardware. It sends char '0' to get the data size and sends char '1' to get the data.

    Chunks of 512 bytes are appended to the data array. When transaction is finished, each received chunk are compared with a fixed 512 bytes pattern that was stored in test array.

    With this custom class, using CreateFile function, the reception is slower in win10 and even more on win7.
    Though we haven't seen specific patterns like zeros or random values, we could see shifting of data similar to the .Net application.

    So here is our current status:
    .Net tool using SerialPort or SerialPort.BaseStreamer
    => Issue with win10
    => No issue with win7

    win32 tool
    => Issue with win10
    => No issue with win7

    Platform versions used for testing:

    Windows 10 Professional 64bit: 1703 (15063.540) with target .NET framework 4.6.2
    Windows 7 Professional 64 bit: SP1

    Thursday, August 31, 2017 7:52 AM
  • Hi, We have simulated the issue using win32 API also (details provided in this thread already). I'm not sure if this is seen already by Microsoft. Is there any other way to report this bug?
    Monday, October 9, 2017 8:52 AM
  • If this problem reproduces in a recent 16299 build (a major update expected to release later this month, you can get it as "insider preview" right  now) - please report a bug.

    -- pa

    • Edited by Pavel A Tuesday, October 10, 2017 8:34 PM
    Monday, October 9, 2017 7:50 PM
  • We confirm that the issue still exists with 16299 build as well.
    Thursday, May 10, 2018 4:22 PM
  • We confirm that the issue still exists with 16299 build as well.

    so much time has passed, and the bug has not fixed still...

    actually for me i have fixed the bug as the feature...

    i think the bug is related to buffers overflow in usbser.sys

    so if i need to send much data i send it by blocks 4kB

    MCU USB-stack is not so fast and between 4kB block the some pauses is appeared to allow usbser.sys flush or switch its buffers

    Friday, May 11, 2018 7:13 AM