none
Run-time error 8020 - Error reading comm device with VB6 app isolated to Win 10

    Question

  • We are experiencing "Run-time error '8020': Error reading comm device" using a PIC18F14K50 USB Module to a VB6 application isolated to Win 10 OS (Home tested not Professional) and not networked.

    Driver versions 5.1.2600.2 and 5.1.26009 work with above USB module and VB6 application on Win XP, 7 and 8.1, but again not on Win 10. The Microchip PIC USB module using these drivers on Win 10 "does" work with non-VB6 applications. Note, above VB6 application works on Win 10 PC with Keyspan USB module and its driver.

    This run-time error has occurred on every PC tested thus far, potentially in the dozens, hence the isolated Win 10 bug claim.

    This issue is critical to our business as our clients aren't able to use our product on Win 10 forcing us to purchase and install older Windows for compatibility.




    • Edited by Davidux Saturday, October 03, 2015 12:41 AM
    Saturday, October 03, 2015 12:37 AM

All replies

  • You might try this... found at

    http://windowssecrets.com/forums/showthread.php/121174-MScomm-Control-6-0

    - Start Regedit.
    - Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}
    - Change the value of Compatibility Flags from 0x0400 to 0.

    Saturday, October 03, 2015 3:04 AM
  • Thanks graye, but this didn't work or did I edit it incorrectly (see below?)

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}]
    "Compatibility Flags"=dword:00000000

    Tuesday, October 06, 2015 3:56 PM
  • I can reproduce the same problem with the Polou USB Micro Controllers, Open works, Write works but Read fails (8020 ); No problems with the exact same code on Win 7 & Win 8; only win 10.  The suggestion below has nothing to do with this problem, it's reacted to a security problem with active X and IE - Don't bother with it
    Tuesday, October 06, 2015 9:49 PM
  • Most VB6 application use Active-X controls to talk to the serial ports.  This is typically done through with their own MSCOMM32.OCX file.  Yes, it is rather odd that Windows uses IE settings to control security for everything related to Active-X controls (even if they are not hosted by IE) 

    So, do you maintain the existing software?  If so you might consider replacing the MSCOMM32.OCX file with an alternative.  There appears to be several... but I can't vouch for any.  Even with a replacement, there's no guarantee that there isn't a new global Active-X security setting somewhere lurking around.

    https://www.google.com/search?q=mscomm.ocx+replacement&ie=&oe=#q=mscomm32.ocx+replacement

    I know you don't wanna hear this, but...   perhaps it's time to replace a 12 year old piece of software with something that's a bit more modern.

    Wednesday, October 07, 2015 6:55 PM
  • You are correct the problem appears to lie in the MSCOMM32.ocx to USBSER interface.  I can replace the MSCOMM32 control with comm32.ocx or scomm32.ocx and these both work correctly under Windows 10 (I've tried and tested).  So the problem is clearly with MSCOMM32.ocx; problem is I have over 250 applications, 25% of them interface with rs-232 or rs-485 devices.  YES, I can replace MSCOMM32.ocx, but MS should fix what they have broken, it probably a simple change in either MSCOMM32 or USBSER.

    MS took years to "really" add serial communications to VB.net (i'm sure than many .net applications still using MSCOMM32.ocx - it was encouraged my MS for quite some time).  But you might say MS has finally done the right thing with the new windows.devices.serialcommunications in win 10.

    The funny thing is I had tested several beta versions of win 10 for compatibility (something MS claims win 10 should be with win7/8), and this problem did not arise with my early tests, so something "got broke" toward the end of the release cycle.  It should be fixed, I should not have to change my code, win 10 should be backward compatible, and it is not.

    Wednesday, October 07, 2015 9:22 PM
  • The same problem was reported by me on August 2015 !!!!!

    Some old VB6 applications using mscomm32.ocx don't work on windows 10.

    NO answer from Microsoft !!!

    here: 

    http://answers.microsoft.com/thread/0e766b05-abb1-4017-81f4-526c7fe21e2d


    • Edited by Guido Pagani Wednesday, November 18, 2015 6:47 PM
    Wednesday, November 18, 2015 6:46 PM
  • Same issue with me.

    Anyone know yet if Microsoft has fixed this ?

    Getting too many prompts to upgrade to Windows 10, but this is a show stopper for me.

    Tuesday, February 02, 2016 11:53 PM
  • Sometimes the easiest answer is the solution. Let me tell at the begining that, I've solved the problem. That is the story:

    I have tried lots of things, but when I was talking to a friend about my problem (who knows nothing on computing and VB6), he told me "I used to use a BIOS setting in older PCs, not to halt on any error such as no diskette driver, no keyboard, don't you have a command like that. OK there is an error but don't care about it, don't warn me about it, don't stop even if there are errors".

    Yes, what he was talking about is the easy, old, sweety "On Error Resume Next" statement!!!

    I hvae used it and my programs started to communicate via MSCOMM32 as they used to. 

    You should better use "On Error Goto" and "Err.Number" to trap other errors instead of this 8020 error. May be there is a real error, may be the USB to RS232 cable disconnected etc.

    And second warning, sometimes On Error Resume Next inludes the subroutines, sometimes it takes a lot of time to understand what is going on (and what is not going on) in your code when you use On Error Resume Next. So, copy your communicating lines to a sub, put an On Error Resume Next at the begining of this sub and call this sub when you need to comminucate devices via MSCOMM32.

    I hope this will be helpful...

    Wednesday, May 11, 2016 11:08 PM
  • I couldn’t believe it would make any difference but I was wrong.

    Now there is one way communication, the output led’s blink as they did before.
    B
    ut obviously there is no input from the 18F2550 available.

    But it was, in a way, helpful...

    Thursday, June 09, 2016 6:42 AM