You click the little toggle for Memory Integrity, fully expecting a satisfying blue switch to slide over and secure your machine.
Instead, Windows throws a deeply annoying yellow warning triangle right in your face. It tells you that Core Isolation cannot be enabled because of an incompatible driver. You click the link to see the offending details, and there it is, staring back at you like a bad joke.
ftdibus.sys
You probably have absolutely no idea what that file is, where it came from, or why it suddenly holds enough power to completely block one of the most critical security features inside Windows 11. You didn’t install it on purpose, right? You certainly didn’t go out of your way to download something called an FTDI bus. Yet, here we are.
This exact scenario drives people crazy.
I see it constantly. Just last year, I was running a massive endpoint security audit for a mid-sized logistics company using the CIS Controls v8 framework. The goal was simple enough—push a Group Policy update to force Hypervisor-Protected Code Integrity (HVCI) across about 400 field laptops. We hit the button. Within an hour, 85 of those machines failed the policy application.
We pulled the telemetry. Every single failure pointed back to ftdibus.sys. We had to pause the entire rollout, physically track down what these field engineers were plugging into their laptops, and manually rip out the driver packages from the Windows Driver Store using command-line tools because the standard graphical interface just wouldn’t let go of them.
It was a nightmare.
But it also forced me to tear apart exactly what this file does, why it exists, and why Microsoft’s security architecture hates it so much. If you want to fix this—and actually understand what you are fixing without just blindly pasting commands into a terminal—we need to unpack the hardware reality hiding behind that tiny .sys extension.
The Ghost in the Machine: What Exactly Is FTDI?
To understand the software, you have to look at the physical plastic and silicon you’ve been plugging into your USB ports.
FTDI stands for Future Technology Devices International. They are a Scottish semiconductor company that makes a very specific, incredibly popular type of microchip. These chips do one thing, and they do it very well—they translate modern USB signals into old-school RS-232 serial data.
Why does that matter?
Because the world still runs on serial connections. While your mouse, keyboard, and webcam all moved to USB decades ago, heavy industrial equipment did not. If you are an IT network administrator configuring a $10,000 Cisco network switch, you plug a console cable into it. That cable has a USB plug on one end and an RJ45 or serial plug on the other. Inside the plastic housing of that USB plug is an FTDI chip.
If you are a hobbyist building a 3D printer, programming an Arduino micro-controller, or flashing custom firmware onto a ham radio, you are using a USB-to-UART bridge. Almost all of them rely on FTDI silicon (specifically the famously ubiquitous FT232R chip).
Even if you aren’t a hardcore tech nerd, you might have picked up a cheap diagnostic cable for your car’s OBD-II port off Amazon. Guess what chip sits inside that cable?
Exactly.
When you plug any of these devices into your Windows machine for the first time, the operating system reaches out to Windows Update—or looks inside its own local repository—and silently installs a driver to make that chip talk to your motherboard. That driver package includes ftdibus.sys.
It sits there, quietly doing its job, translating voltages and bits so your computer can talk to a router, a 3D printer, or a car engine. Most of the time, you never even know it is there.
The Collision: Why Memory Integrity Hates Your Serial Cable
So, the chip is normal. The cable is normal. Why is Windows Security suddenly treating it like a toxic threat?
To grasp this, we have to look at what Memory Integrity actually is. Microsoft officially calls this feature Hypervisor-Protected Code Integrity (HVCI). It is arguably the most aggressive and effective security feature introduced to the consumer Windows operating system in the last decade.
Before HVCI existed, the Windows kernel—the absolute core brain of the operating system—lived in the same basic hardware reality as everything else. If a piece of software had “administrator” or “system” level privileges, it could largely write whatever it wanted directly into the system’s active memory.
Hackers loved this.
They would write malicious code, sneak it into the kernel memory space, and hide it there. Because the malware was running at the exact same privilege level as the antivirus software trying to find it, the malware could simply lie to the antivirus. “Nope, nothing to see here in this sector of RAM.”
Microsoft got sick of this game of whack-a-mole. They introduced Virtualization-Based Security (VBS). When you turn on your computer now, Windows doesn’t actually boot directly on the bare metal of your motherboard. Instead, a tiny, invisible hypervisor boots up first. This hypervisor creates a secure, isolated bubble—a vault—and puts the most sensitive parts of the Windows kernel inside it.
This is Core Isolation.
Memory Integrity is the bouncer standing at the door of that vault.
The bouncer has one very strict rule: No code can be both writable and executable at the same time.
Think about that for a second. If a block of computer memory can be written to (meaning you can change the data inside it) AND executed (meaning the computer will run whatever instructions are sitting there), it is a massive security hole. A hacker can write a malicious script into that memory block and immediately force the computer to execute it.
Modern, secure software separates these things strictly. Memory is either for storing data (writable) or for running established programs (executable). Never both.
The Sins of the Past
Here is where ftdibus.sys ruins the party.
Many hardware manufacturers are notoriously lazy when it comes to writing software drivers. Back in the Windows 7 and Windows 8 days, there were no strict HVCI rules. Driver developers would routinely ask the operating system for memory pages that were both writable and executable just because it was easier and faster to code that way. It was sloppy, but it worked fine at the time.
FTDI released several versions of their USB-to-serial drivers between 2012 and 2018 that did exactly this.
They didn’t do it to be malicious. They did it because hardware engineers are rarely great software engineers. They just wanted the serial port to push data as fast as possible without dropping packets.
Now, fast forward to today. You hit the toggle to turn on Memory Integrity. The Windows hypervisor does a quick scan of every single driver registered on your system. It looks at the ftdibus.sys file sitting in your System32 folder. It reads the code and realizes that if this driver ever wakes up, it is going to demand writable and executable memory.
The hypervisor panics.
If it allows Memory Integrity to turn on, and then you plug in your USB serial cable, the FTDI driver will try to execute its sloppy memory request. The hypervisor will violently block it. Because drivers operate at the kernel level, this sudden block will instantly crash your entire computer. You will get a Blue Screen of Death (BSOD) immediately.
To save you from a random, unexplainable blue screen the next time you plug in a 3D printer, Windows simply refuses to turn on Memory Integrity. It flags the driver as incompatible and grinds the whole security upgrade to a halt.
Why Is It So Hard to Get Rid Of?
This is the part that usually sends people straight to Reddit in a blind rage.
You see the error. You figure, “Okay, I’ll just delete the file.” You open File Explorer, navigate to C:\Windows\System32\drivers, find ftdibus.sys, hit the delete key, and Windows laughs at you. It throws an “Access Denied” or “File in Use” error. Even if you manage to delete it by booting into Safe Mode, the second you reboot, the Memory Integrity error is still there.
Why?
Because you are fighting the Windows Driver Store.
Starting with Windows Vista, Microsoft fundamentally changed how drivers are handled. They created an ironclad vault called the Driver Store (located at C:\Windows\System32\DriverStore\FileRepository). When you plug in a new device, Windows doesn’t just install the driver directly. It places a master copy of the driver package into the Driver Store. Then, it creates active copies for the system to use.
If you just delete the active copy in the drivers folder, Windows assumes the file got corrupted. It quietly reaches into the Driver Store, grabs the master copy, and puts it right back.
You cannot defeat the Driver Store with the delete key.
Even worse, you might try opening Device Manager to uninstall it. But if the physical USB cable isn’t currently plugged into the computer, the device is hidden. It doesn’t show up in the list. You are fighting a ghost.
The Tactical Strike: How to Actually Fix This
We need to surgically remove the offending FTDI package from the Driver Store itself. To do this, we abandon the graphical interface entirely and drop down into the command line.
This process relies on a built-in Windows utility called pnputil (Plug and Play Utility). It is the exact tool system administrators use to manage driver packages at scale. It is powerful, unforgiving, and exactly what we need.
Phase 1: Finding the True Name
Windows doesn’t store the driver in the Driver Store under the name ftdibus.sys. It stores the entire package under an “OEM” file name. We have to find out which OEM file contains the FTDI driver.
- Click your Start button, type
cmd. - Do not just hit enter. You must right-click Command Prompt and select Run as administrator. If you skip this, nothing will work.
- Once the black window opens, type the following command exactly as written and hit Enter:
pnputil /enum-drivers
Your screen is going to explode with text. Hundreds of lines will scroll past. Don’t panic. This is just Windows listing every single third-party driver package currently locked inside the Driver Store.
You need to scroll back up through this massive list and look for the FTDI entry. You are looking for a block of text that looks something like this:
Published Name: oem42.inf
Original Name: ftdibus.inf
Provider Name: FTDI Ltd.
Class Name: Universal Serial Bus controllers
Class GUID: {36fc9e60-c465-11cf-8056-444553540000}
Driver Version: 08/16/2017 2.12.28.0
Signer Name: Microsoft Windows Hardware Compatibility Publisher
The critical piece of information here is the Published Name. In my example above, it is oem42.inf. On your computer, it will almost certainly be a different number. It might be oem15.inf, oem9.inf, or oem112.inf. Write that exact number down.
(A quick pro-tip: If you don’t want to scroll through all that text manually, you can force the command prompt to search for you. Type pnputil /enum-drivers | findstr /i "ftdi". This will filter the noise and just spit out the lines containing the word FTDI, helping you narrow down the correct OEM number much faster).
Phase 2: The Eradication
Now that you have the target locked, it is time to execute the removal. You are going to tell the Plug and Play utility to forcibly delete that specific OEM package from the system.
Type the following command, replacing oem42.inf with whatever number you found on your specific machine:
pnputil /delete-driver oem42.inf /uninstall /force
Let’s break down exactly what you are telling the computer to do here.
- /delete-driver oem42.inf — This targets the master package in the protected Driver Store.
- /uninstall — This tells Windows to actively detach the driver from any hidden or disconnected hardware profiles currently lingering in the registry.
- /force — This is the heavy-duty hammer. If Windows complains that the driver is “in use” by a background process, this flag tells the OS to ignore the warning and rip it out anyway.
Hit Enter.
If you typed it correctly, you should see a brief message confirming that the driver package was deleted successfully. Just like that.
Phase 3: The Clean Up
Here is a frustrating reality—sometimes, there is more than one FTDI driver hiding in the system. Many users have plugged in different cables over the years, accumulating multiple incompatible versions of the same core driver.
You need to run the pnputil /enum-drivers command again. Search the list one more time. Is there another package labeled FTDI? Maybe an ftdiport.inf hiding under a different OEM number? If there is, repeat the deletion command for that new number.
Keep hunting them down until the list is completely clean of anything bearing the FTDI provider name.
Once you are absolutely sure they are gone, restart your computer. A reboot is absolutely mandatory here. The Windows hypervisor only evaluates code integrity rules during the bootloader phase. It needs a fresh start to realize the toxic files are finally gone.
When the computer boots back up, open Windows Security, navigate to Device Security, click Core Isolation details, and hit that Memory Integrity toggle. It will slide over to the “On” position, ask for one more reboot to lock the hypervisor into place, and you are finally secure.
But Wait, I Actually Still Need My Serial Cable!
This is the exact question my client’s field engineers asked me after we nuked their drivers.
If you actually use a USB-to-serial cable for work or a hobby, you might be panicking right now. Did we just permanently break your ability to connect to your CNC machine or your Cisco router?
No.
The problem was never the hardware. The problem was an incredibly outdated, sloppy version of the software. FTDI is a massive company; they did not just ignore this issue. Once Microsoft made HVCI a strict requirement for Windows 10 and 11, FTDI went back to the drawing board and completely rewrote their driver architecture from scratch.
They released new driver packages (version 2.12.36.4 and newer) that perfectly comply with modern memory allocation rules. They no longer ask for writable and executable memory blocks. They play nice with the hypervisor.
If you need your cable to work again, you simply need the modern driver.
Do not rely on Windows Update for this. Microsoft’s driver repository is notoriously slow to update legacy hardware catalogs. Sometimes, plugging the cable back in will just pull down the exact same broken 2017 driver you just spent twenty minutes deleting.
Instead, open your web browser and go directly to the official FTDI website (ftdichip.com). Navigate to their Drivers section, specifically looking for the VCP (Virtual COM Port) drivers. Download the latest executable setup file for Windows.
Run that installer *before* you plug your cable back in. This pre-populates your Driver Store with the clean, HVCI-compliant version. When you finally connect the USB plug, Windows will see the fresh, secure driver, bind it to the hardware, and your serial connection will light up instantly—all while Memory Integrity remains fully active and unbroken.
Understanding the Battlefield: Legacy vs. Modern Architecture
If you want a clearer picture of exactly what changed under the hood, I’ve mapped out the technical differences between the old driver behavior and the new standard. This is the exact kind of data Microsoft’s engineers look at when classifying a driver as a security risk.
| Driver Characteristic | Legacy FTDI Drivers (Pre-2018) | Modern FTDI Drivers (v2.12.36.4+) |
|---|---|---|
| Memory Allocation Request | Non-Paged Pool (Executable) | Non-Paged Pool (No-Execute / NX) |
| W^X Rule Compliance | Fails. Requests Write+Execute simultaneously. | Passes. Strictly separates Write and Execute pages. |
| HVCI / Core Isolation Status | Hard Block. Triggers incompatible driver warning. | Fully Supported. Runs inside the secure hypervisor boundary. |
| Windows Hardware Quality Labs (WHQL) | Signed for older OS (Win 7/8), grandfathered into Win 10. | Strictly signed against modern Windows 11 DCH standards. |
| Removal Method | Requires pnputil forced removal from Driver Store. |
Standard uninstallation via Device Manager works cleanly. |
Looking at that table, it becomes incredibly obvious why Microsoft drew a hard line in the sand. The old method of dumping executable code into a non-paged memory pool was a ticking time bomb waiting for a buffer overflow attack.
The Counterfeit Chip Problem (A Brief History Lesson)
There is one more layer to this puzzle that explains why your machine might be clinging to a particularly weird, stubborn version of the FTDI driver. It involves a massive controversy from 2014 known in hardware circles as “FTDI Gate.”
Because FTDI chips were so popular and relatively expensive compared to generic silicon, Chinese manufacturing markets were flooded with cheap, counterfeit clones. These clones looked identical to genuine FTDI chips and identified themselves to Windows using the exact same hardware ID.
FTDI was furious.
In a highly controversial move, FTDI released a driver update via Windows Update that actively hunted down counterfeit chips. If the driver detected fake silicon, it didn’t just refuse to work—it intentionally rewrote the USB product ID burned into the physical chip to 0000. It permanently bricked the counterfeit hardware.
The tech community exploded with anger. People had bought expensive Arduinos or diagnostic cables in good faith, completely unaware they contained cloned chips, only to have a Windows Update physically destroy their hardware.
Microsoft eventually forced FTDI to pull that aggressive driver. But the fallout was massive. Dozens of hardware vendors, terrified of bricking their customers’ devices, stopped using the official FTDI drivers. They started tweaking, modifying, and renaming older, “safe” versions of the driver and packaging them natively with their software.
This created an absolute mess in the Windows ecosystem. Instead of one unified, easily updatable FTDI driver, there were hundreds of weird, fragmented, OEM-branded versions floating around. Many of these modified drivers were abandoned by the hardware creators years ago. They never received the modern updates required to pass HVCI checks.
That is why you might find three or four different oem.inf files hiding in your system when you run the pnputil command. You aren’t just cleaning up FTDI’s mess; you are cleaning up a decade of hardware supply chain drama.
What If the Command Line Fails? (Advanced Tactics)
I want to be realistic with you. Sometimes, even the /force flag in pnputil isn’t enough. Windows is a complex beast, and occasionally, a driver gets its hooks so deeply embedded in the system registry that the standard uninstaller just chokes.
If you hit Enter on that command and get a red error message saying the system cannot find the file specified, or access is completely denied, you have to escalate your tactics.
When I run into a truly stubborn machine—usually a heavily locked-down corporate laptop with deep endpoint protection agents running interference—I skip the standard command prompt and lean on a Sysinternals tool called PsExec.
You see, running a command as “Administrator” is not actually the highest level of power in Windows. There is a hidden, internal user account called NT AUTHORITY\SYSTEM. It is the god-mode account that the operating system itself uses to manipulate files.
If you download the Sysinternals Suite directly from Microsoft, you can open a command prompt as the SYSTEM account by running:
psexec -i -s cmd.exe
A new black window will pop open. It looks identical to the old one, but if you type whoami, it won’t say your username. It will say nt authority\system.
Running the pnputil /delete-driver command from this specific window bypasses almost all user-level file locks. It is the digital equivalent of taking an angle grinder to a stuck bolt. It works every single time.
(Just be incredibly careful in that SYSTEM window. There are no safety nets. If you accidentally delete the wrong OEM file—say, the driver for your laptop’s NVMe hard drive—your computer will never boot again.)
The False Positives: Exploring the Registry
There is a very rare, deeply annoying edge case I want to cover. Let’s say you’ve done everything right. You ran the commands. You deleted every trace of FTDI. The Driver Store is spotless. You rebooted.
You go back to Windows Security, and the Memory Integrity toggle *still* refuses to turn on, pointing to a phantom ftdibus.sys that literally does not exist on your hard drive anymore.
This happens when the Windows Registry gets out of sync with the physical file system. The hypervisor checks the registry for a list of registered services during boot. If it sees a key telling it to expect the FTDI driver, it flags it as incompatible, even if the actual .sys file was deleted.
To fix a phantom registry flag, you have to go into the Registry Editor.
- Hit the Start button, type
regedit, and run it as administrator. - Carefully navigate down this exact path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services - Scroll down the massive list of folders on the left side until you find one named
FTDIBUS. - Right-click that
FTDIBUSfolder and delete it entirely.
This rips out the service registration. It tells Windows to stop expecting the driver to load. Once you delete that key and reboot the machine one final time, the ghost is fully exorcised. Memory Integrity will finally engage.
Why You Shouldn’t Just Ignore It
I know a lot of people who hit this roadblock, get frustrated, and just give up. They leave Memory Integrity permanently turned off. “My computer runs fine without it,” they say. “Why bother?”
I strongly advise against that mindset.
Leaving Core Isolation disabled in the modern threat environment is like leaving the front door of your house wide open because the deadbolt was a little sticky. The type of malware that HVCI prevents is not the annoying adware that pops up in your browser. It is deep, persistent, kernel-level threats.
Ransomware gangs absolutely love machines with HVCI disabled. If they can get a foothold on your machine via a phishing email, and Memory Integrity is off, they can drop a malicious driver into your kernel space. Once they are in the kernel, they can silently turn off your antivirus, encrypt your hard drive from the inside out, and completely lock you out of your own data before you even realize what is happening.
Microsoft didn’t make Memory Integrity the default standard in Windows 11 just to annoy you. They did it because kernel-level attacks have become shockingly common. The minor inconvenience of spending fifteen minutes in the command prompt deleting a stubborn serial driver is a tiny price to pay for locking down the most vulnerable part of your operating system.
Alternative Hardware Solutions
If you’ve gone through all this trouble and you are thoroughly sick of dealing with FTDI drivers entirely, you do have other options. The hardware market has shifted.
While FTDI was the undisputed king of serial communication for a long time, competitors have caught up. If you are buying a new console cable or looking for a serial adapter for a project, keep an eye out for cables built around different chipsets.
The two most common alternatives are the Prolific PL2303 and the WCH CH340.
The Prolific chips are very common in commercial networking cables. Their drivers have generally been kept very up-to-date and play perfectly nicely with Windows 11 Core Isolation right out of the box.
The CH340 chip is an ultra-cheap Chinese alternative that has completely taken over the hobbyist market. If you buy a cheap Arduino clone off AliExpress today, it almost certainly uses a CH340 chip instead of an FTDI one. Surprisingly, despite being incredibly cheap, the modern CH340 Windows drivers are actually fully HVCI compliant. They install quietly, work reliably, and don’t trigger any security alarms.
Switching your physical hardware to one of these alternative chipsets is a completely valid way to bypass the FTDI headache entirely, especially if you just need a simple, reliable serial connection without the historical baggage.
The Final Takeaway
Dealing with ftdibus.sys feels like a punishment for trying to secure your computer. It is a frustrating clash between decades-old hardware standards and hyper-modern software security.
But it isn’t magic. It isn’t a virus. It is just a messy, outdated file sitting in a protected vault.
Now you know exactly how that vault works. You know how to bypass the graphical interface, query the Driver Store directly, identify the specific OEM package hiding the bad code, and forcibly rip it out of the system. You’ve essentially learned how to perform a manual, surgical strike on the Windows kernel environment.
That is a genuinely powerful skill.
So, the next time you see that yellow warning triangle, don’t ignore it. Don’t let a tiny piece of Scottish silicon from 2017 dictate the security posture of your modern machine. Open up that command prompt, find the OEM number, drop the hammer on it, and slide that Memory Integrity toggle over to where it belongs.
