Need help creating a virtual serial port on Windows

Serial Communication
1

I’m trying to set up a virtual serial port on my Windows PC so I can test software that expects a COM port, but I’ve never done this before. I’m not sure which tools or drivers I should use, or how to properly configure the ports so two apps can talk to each other. Can someone walk me through the easiest reliable way to create and test a virtual serial port pair?

2

If you want to test software that expects a COM port without real hardware, you need a software-based COM port emulator on Windows. The usual term people search for is something like “Windows virtual COM port emulator” or “virtual RS232 port for testing serial apps”.

Most common options:

  1. Virtual Serial Port Driver (Eltima / Electronic Team)

    • Creates pairs of virtual COM ports, for example COM5 and COM6.
    • Your test program opens COM5, your other tool connects to COM6. Data goes both ways.
    • Lets you set baud, parity, flow control, etc, so your app behaves like it talks to a real UART.
    • Good fit if you need multiple virtual ports, or stable behavior on newer Windows versions.
    • This is paid, but the feature set is strong and people use it in production test setups.

  2. Free or simpler tools

    • com0com: open source, but setup is more manual. Driver signing on modern Windows can be a pain.
    • VSPE: has a free 32‑bit version, limited for heavier use.

Basic setup with a tool like Virtual Serial Port Driver:

  1. Install the driver and reboot if it asks.
  2. Create a “pair” of ports, for example COM7 and COM8.
  3. In your test software, pick COM7 and set the serial parameters it expects.
  4. Use a terminal program like PuTTY, Tera Term, or RealTerm to open COM8.
  5. Send text from the terminal. You should see it inside your app.
  6. Send data from your app. Check that it appears in the terminal.

Typical config tips:

  • Match baud rate, data bits, parity, stop bits, and flow control on both sides.
  • If the app needs RTS/CTS or DTR/DSR, enable hardware flow control in the driver settings.
  • Use low COM numbers like COM3 to COM9 if your app is old. Some tools fail on COM ports above COM9.

If you want a quick overview of how a tool like Virtual Serial Port Driver works in practice, this video is useful:
setting up a reliable Windows virtual COM port

Once you get a loopback pair working, you can expand to multiple ports and script tests around them.

Need help creating a virtual serial port on Windows
Need help creating a virtual serial port on Windows1536×864 150 KB

1 Like
3

If you just want software that “pretends to be” a COM port so your app stops whining about missing hardware, there are a few paths that weren’t covered by @voyageurdubois, or at least not in the same way.

First, quick clarification: decide what you actually need:

  1. Your app just needs a port to open and maybe exchange some test data.
  2. Your app needs to be connected to another app or tool (like a terminal, logger, simulator).
  3. Your app is very picky about signals like RTS/CTS, DTR/DSR, etc.

Depending on which it is, here are some angles:

1. Built around actual USB to serial (yeah, still “virtual” in Windows)

This sounds dumb at first, but it’s often the least painful.

  • Grab a cheap USB to RS‑232 adapter (FTDI or even CH340).
  • Windows creates a virtual COM port automatically with the vendor’s driver.
  • Your app talks to that COM port like it’s “real hardware,” because it is from Windows’ point of view.

Pros:

  • No unsigned driver hell.
  • Signals like DTR/RTS behave close to real hardware.
  • Very stable on modern Windows versions.

Cons:

  • You need physical hardware plugged in.
  • You still need a loopback for testing (e.g. connect TX to RX or use a second adapter).

If you’re mostly worried about config headaches and driver signing, this is honestly the cleanest path.

2. Using Virtual Serial Port Driver but in a slightly different pattern

@voyageurdubois described the classic “pair of ports” setup. I agree it’s solid, but I would tweak how to use it:

  • Install Virtual Serial Port Driver from Electronic Team.
  • Instead of just a single pair, set up:
    • One pair for your main app to talk to a test harness.
    • Optionally another pair reserved for low level debugging or protocol sniffing.

This software lets you:

  • Create multiple port pairs with specific COM numbers.
  • Emulate real serial line parameters so your legacy app does not freak out.
  • Work reliably on modern Windows versions (unlike some old free tools that require driver signing hacks).

And if you want a detailed feature breakdown or downloads, check out advanced tools for creating virtual COM ports on Windows.

That page is much easier to digest than trying random “COM emulator” downloads from shady sites.

3. Using TCP instead of pure COM, with a bridge

This is where I mildly disagree with stopping at just COM pairs. Sometimes a TCP to serial bridge setup is way cleaner if your app will eventually talk over network protocols or you are simulating a device that already has a TCP server.

Example setup:

  1. Use Virtual Serial Port Driver (or similar) to create a single virtual COM port.
  2. Run a small “COM to TCP bridge” tool that exposes that port on localhost:port.
  3. Your simulator or second app connects over TCP to that port.

Advantages:

  • Easier to script and debug with tools like netcat, Python, etc.
  • Lets you gradually migrate to a network-based test harness.
  • Good for automation in CI environments.

If your app only needs “something that opens as COM3 and echoes data,” this method can still work, just with more flexibility.

4. Config details people skip that actually bite you

Stuff that causes mysterious failures:

  • COM number > 9:
    Some older software cannot handle COM10+ unless you use \\.\COM10 style paths, which those apps usually do not. Stick to COM3–COM8 when possible.

  • Flow control mismatch:
    If your app expects RTS/CTS and your virtual link is not configured for hardware flow control, you get silent failures, half transmitted data, or “hangs.”

  • Startup order:
    Some apps enumerate ports only at launch.
    So:

    • Create virtual ports first.
    • Then start your app.
      Otherwise it may never “see” the new COM port.

  • Permissions / UAC:
    On some systems, the driver part needs admin rights to install and create ports but your app may run normal user mode. Make sure you’re not blocked by that.

5. Minimal test that proves your chain works

My recommended sanity check:

  1. Create virtual COM pair with Virtual Serial Port Driver, say COM5 and COM6.
  2. Open COM5 in your app.
  3. Open COM6 in a terminal tool like Tera Term or RealTerm.
  4. Type in the terminal and see what appears in your app.
  5. Send whatever test payload your app sends and make sure the terminal sees it correctly.

If that roundtrip works:

  • Your virtual driver is configured correctly.
  • Any future issues are probably in your app logic, not the COM layer.

So, to summarize in practical terms:

  • If you want zero driver drama and can live with hardware: cheap USB–serial adapter.
  • If you want flexible, software-only, production-worthy virtual COM pairs: Virtual Serial Port Driver is the straightforward choice.
  • If you want future-proof, scripted, maybe network-based testing: combine a virtual COM with a TCP bridge.

Once you have a stable virtual COM, the main work is just keeping baud / parity / flow control in sync on both ends and choosing a COM number your legacy app can actually open without choking.

Need help creating a virtual serial port on Windows
Need help creating a virtual serial port on Windows1536×1029 234 KB

4

If you want to go a bit beyond what @caminantenocturno and @voyageurdubois already covered, think in terms of how you want to test, not just what tool to install.

Both of them pointed you in the right direction with virtual port pairs and the usual suspects like com0com, VSPE and particularly Virtual Serial Port Driver. I slightly disagree with relying too heavily on the old free stacks as a primary option on current Windows though. Driver signing workarounds and random breakage after a Windows update are exactly what you do not want when you are trying to debug your own app.

Here is how I would structure it:

1. Start with the simplest topology that matches your test goal

  • If you only need to check that your app can:

    • open a COM port
    • set baud/parity
    • send or receive some bytes

    then a single virtual pair is enough. One side is your app, the other side is a terminal or a tiny test tool.

  • If you are simulating a device protocol (say a custom binary protocol or Modbus-like chatter), treat the second port as a “device simulator” endpoint and run a script or helper app there.

2. Virtual Serial Port Driver: where it shines and where it annoys

Pros:

  • Very stable on modern Windows compared to many free drivers.
  • Easy GUI to create and delete COM pairs without registry hacking.
  • Handles multiple pairs nicely when you scale your tests.
  • Good support for control lines (RTS, CTS, DTR, DSR etc.) which matters if your app is picky.

Cons:

  • Paid license, so not ideal if this is a one-off hobby project.
  • Slightly heavy for the “I just want one fake COM4 that always opens” scenario.
  • Overkill if you never touch flow control or advanced options.

If you see yourself doing repeated testing, automation, CI or supporting several legacy apps, the cost starts to look reasonable. For a student project or a quick check, it might feel like too much.

3. Alternatives with a different angle

  • com0com
    Good for people who are comfortable with manual driver setup and possibly dealing with certificate / test signing mode on newer Windows. Once you get it running it is lean and effective, but it is not what I would hand to a beginner who just wants to click “Create COM5 and COM6.”

  • VSPE
    Nice for lightweight, smaller setups. Limited free edition and 32‑bit constraints mean it is better suited to older tools or simple test beds, not a big multi‑port test rig.

Both are fine, and what @caminantenocturno / @voyageurdubois mentioned is valid, but they tend to cost you more time if Windows decides to be strict about drivers.

4. One trick people forget: “fake” device behavior

Once you have something like Virtual Serial Port Driver installed and a pair created, the interesting part is not the driver itself but how you simulate the device:

  • For a text based protocol, you can literally use a terminal on the other end and type responses.
  • For a binary protocol, use a small script (Python with pyserial, C#, etc.) that:
    • Opens COMx (the peer port).
    • Listens for specific byte sequences.
    • Responds with canned frames.

This lets you reproduce device edge cases: bad checksums, delayed responses, abrupt disconnects, without needing real hardware.

5. When I would not use a virtual driver

If you eventually must deal with real RS‑232 electrical quirks or USB adapter oddities (timing, control signals flickering on plug/unplug), then I actually side more with the “cheap USB to serial adapter” approach mentioned indirectly in the other post. A pure software virtual port will not expose certain hardware-level issues. For logic level protocol testing it is perfect; for physical-layer quirks it is not.

Bottom line

  • For a clean, repeatable, Windows friendly test environment, a commercial tool like Virtual Serial Port Driver is usually the least painful, especially if you care about control lines and multiple ports.
  • For maximum “free,” com0com / VSPE still work but you pay with setup effort and maintenance.
  • Decide first what kind of tests you want to run, then pick the tool. The virtual port is just plumbing; the real win comes from how you script or simulate the “other side” of that COM link.