External Monitor Not Detected After macOS 26 Upgrade

Just to help others Deep System Reset by abhiraj_chatterjee worked here too.

So the culprit was corrupted display preference files left behind by the macOS Tahoe upgrade. Not the hardware, not the cable, not the display switch. macOS had cached bad display settings and was silently rejecting the connection every time based on that stale data.

To recap the full journey for anyone who ever finds this:

• Philips BDM3270 stopped working with M1 MacBook Air after upgrading to macOS Tahoe (26)
• Both HDMI and DisplayPort inputs appeared dead - no signal, nothing in System Settings
• The fix: delete the corrupted windowserver plist files and restart:

Unplug monitor and run The Deep System Reset script posted by abhiraj_chatterjee:

bash

rm -f ~/Library/Preferences/ByHost/com.apple.windowserver.displays*.plist
sudo rm -f /Library/Preferences/com.apple.windowserver*.plist
sudo killall Dock

Then restart, plug back in after restart -> display works again fine.

Hi everyone,

Just spent 2 hours on this and found a fix that doesn't involve buying a USB-C adapter, so I figured I'd share since every thread I read ends with "just get a dongle".

My setup: MacBook Pro 14" M2 Pro, macOS Tahoe 26.5, Samsung monitor over HDMI plugged directly into the Mac's built-in HDMI port. Classic symptom, the monitor powers on but stays black, and the Mac doesn't see it at all. Nothing in System Settings, nothing in system_profiler SPDisplaysDataType, nothing in IORegistry. The same HDMI cable works fine on my TV, and the monitor used to work with this Mac before the Tahoe upgrade.

I tried everything you usually find on forums: multiple HDMI cables, rebooting with the monitor already plugged in, updating macOS (26.4.1 then 26.5), disabling VRR on the monitor, Option+Detect Displays in System Settings. Nothing changed.

What ended up working is one command in Terminal, no sudo needed:

mv ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist ~/Desktop/

Then plug the HDMI cable in, restart via the Apple menu, and on boot the monitor is detected right away.

Why it works. macOS keeps a cache of every display it has ever seen in this file. On my Mac there were 11 configurations stacked up across 8 different displays (old TVs, meeting room projectors, previous office monitors, you name it), and several of them were in a clearly broken state: dimensions of 1x1 pixels, origin coordinates at -3200, a mix of Sequoia and Tahoe formats in the same file. Tahoe became way stricter about validating this file, where Sequoia would just silently ignore invalid entries. So the entire display detection pipeline gets stuck on the first malformed entry it hits, and the HDMI handshake never even starts with a new monitor.

The mv sends the file to the Desktop instead of deleting it, so you have an automatic backup. If anything goes weird you can put it back:

mv ~/Desktop/com.apple.windowserver.displays.*.plist ~/Library/Preferences/ByHost/

Hope this helps someone.

Macbook Pro M4 Max 128GB RAM, OS 26.0.1. -> Kensington TB4 Docking Station, LG 49W-L59C Monitor (attached via USBC to Docking Station).

With me everything Thunderbolt (I have a Thunderbolt 4 Dock by Kensington that has been the MBP's primary companion since I brought it home) takes random dumps flapping disconnect/connect after upgrading to OS 26. As others say, undesired behavior stops if you reboot with the TB4 dock connected, or if you leave it alone for a while with the lid open and just wait it out for a *very* long time (1/2h or more, every flap seemingly "lasting longer" on until I feel I can finally close the lid). Open or closed lid doesn't matter (though closed lid goes to sleep eventually).

It flaps all my TB peripherals back and forth as well, so it's the connection dock-Macbook, not USBC monitor-dock. It's insane and it was all working perfectly before the upgrade.

Setup works well with other devices including an non-upgraded Macbook Air M2 I also own.

You can claim "now we perfect video with no dropped frames" all you want, but graceful degradation on regular usage really is table steaks expected behavior in 2025 (and that it "eventually fixes itself" with lid open suggests a software bug, not cables). Submitted a bug and everyone who can reproduce should as well.

I write software (but not Kernel stuff). Here's a log around one of the flip-flaps (filtered by IOThunderboltSwitch) in case interested Apple devs see this.

default	16:31:54.565680-0700	kernel	130796819157us IOThunderboltSwitch(0@1)::finalize - terminate device: Kensington TB4 Docking Station (047d:809b:01) (8087:0b26:03)
default	16:31:55.780139-0700	kernel	130798033610us IOThunderboltSwitch(0@0)::processPlugEvent - Thunderbolt HPD packet for rid = 0 route = 0x0 port = 2 plug = 1
default	16:31:55.780402-0700	kernel	130798033873us IOThunderboltSwitch(0@0)::processPlugEvent - Thunderbolt HPD packet for rid = 0 route = 0x0 port = 1 plug = 1
default	16:31:55.895400-0700	kernel	130798148869us IOThunderboltSwitch(0@1)::syncTargetAndNegotiatedWidth - port (0@0:2) - bonding took 0 ms
default	16:31:55.895863-0700	kernel	130798149332us IOThunderboltSwitch(0@0)::processPlugEvent - Thunderbolt HPD packet for rid = 0 route = 0x0 port = 2 plug = 0
default	16:31:55.907162-0700	kernel	130798160632us IOThunderboltSwitch(0@1)::processPlugEvent - Thunderbolt HPD packet for rid = 0 route = 0x1 port = 2 plug = 0
default	16:31:55.960740-0700	kernel	130798214209us IOThunderboltSwitchIntelJHL8440(0@1)::overrideSupportedCLxStates - clx = 0x00000000
default	16:31:55.961412-0700	kernel	130798214881us IOThunderboltSwitch(0@1)::configureCLx - (0x1 -> 0x1) supported = 0x7 common = 0x0 parent = 0x7 child = 0x0 options = 0x0 enable = 1 current = 0x0 target = 0x0 status = 0x00000000
default	16:31:55.993346-0700	kernel	130798246815us IOThunderboltSwitchIntelJHL8440(0@1)::overrideSupportedCLxStates - clx = 0x00000000
default	16:31:55.994040-0700	kernel	130798247510us IOThunderboltSwitch(0@1)::configureCLx - (0x1 -> 0x1) supported = 0x7 common = 0x0 parent = 0x7 child = 0x0 options = 0x0 enable = 1 current = 0x0 target = 0x0 status = 0x00000000
default	16:31:56.004702-0700	kernel	Sandbox: ThunderboltAccessoryUpdaterServi(1256) allow iokit-get-properties iokit-class:IOThunderboltSwitchType7 property:Router ID
default	16:31:56.144109-0700	kernel	130798397578us IOThunderboltSwitchIntelJHL8440(0@1)::overrideSupportedCLxStates - clx = 0x00000000
default	16:31:56.144807-0700	kernel	130798398275us IOThunderboltSwitch(0@1)::configureCLx - (0x1 -> 0x1) supported = 0x7 common = 0x0 parent = 0x7 child = 0x0 options = 0x0 enable = 1 current = 0x0 target = 0x0 status = 0x00000000
default	16:31:56.594343-0700	kernel	130798847808us IOThunderboltSwitch(0@1)::processPlugEvent - Thunderbolt HPD packet for rid = 0 route = 0x1 port = 13 plug = 1
default	16:31:56.691675-0700	kernel	130798945140us IOThunderboltSwitchIntelJHL8440(0@1)::overrideSupportedCLxStates - clx = 0x00000000
default	16:31:56.692414-0700	kernel	130798945879us IOThunderboltSwitch(0@1)::configureCLx - (0x1 -> 0x1) supported = 0x7 common = 0x0 parent = 0x7 child = 0x0 options = 0x0 enable = 1 current = 0x0 target = 0x0 status = 0x00000000

While cable changes may work for others, it hasn't been the case for me. My cables are new T5/80Gb cables (I already paid for a maxed out M4 Max, what's a TB cable?)

What sucks is that every other laptop including my Linux laptops of a huge range of versions and generations all work and behave beautifully with this exact setup... but what's by far the most expensive machine I've ever bought, decides to take random dumps now. It's just frustrating and makes me feel like I wasted my money here (when I know a crappy bus implementation when I use one; I mean, I have windows machines too).

I really hope they fix this. Soon. It's not okay since it hits me at least 2x/day as I move around with my laptop as one does.

Good luck everyone, hope any of this helps.

Thank you for your excellent, detailed report. I expect to send other users to read it for guidance.

for those who are Terminal-averse, those preference files CAN be accessed through Finder.

To access the folder using Finder for the system-wide preference

Copy and paste this string into:

Finder > Go menu > Go to Folder

/Library/Preferences

then find and delete this file:

/Library/Preferences/com.apple.windowserver

-AND- To access the folder for your-user preference

Copy and paste this string into:

Finder > Go menu > Go to Folder

~/Library/Preferences

then find and delete whichever of these two files you find:

~/Library/Preferences/com.apple.windowserver.<UUID>.plist -OR-

~/Library/Preferences/ByHost/com.apple.windowserver.<UUID>.plist

-- where [~] tilde is an active abbreviation for "current user"

-- and <UUID> is a string of hexadecimal numbers unique to your system, grouped as 8-4-4-4-8 hexadecimal digits

Restart REQUIRED after these deletions.

<< I don't understand the logic behind recommending that the cable is the issue. The cable worked moments before I did the macOS 26 upgrade, with the same computer, monitor, and cable. Once the software was updated, the setup didn't work. This thread has many views compared to all other Tahoe topics, likely meaning others are searching for this same issue. >>

This is not an issue of BROKEN cables. Users are finding their cables do not meet the demanding requirement of connecting high-end displays to recent Macs with the latest MacOS.

Modern displays are running very close the the maximum speeds the logic can switch, and still be recognizable at the other end. And MacOS has become increasingly demanding that NO transmit errors occur, such as those caused by low spec cables or cables that exceed the maximum length.

<< The USB-C to USB-C cable I was using came with a monitor. I also tried a USB-C cable that comes with other Apple products. Both have the same result. >>

Cables "shipped in the box" are infamous for being 'lowest bidder' cables, just good enough to keep you from returning the device the same day you bought it.

Found cables of any description might be anything.

That is why I spelled out what specifications high-end cables for this use must have. Cable LENGTH is not negligible.

<< I will try to order a Thunderbolt cable. If that solves the issue, I will report back. However, it's silly that a software update now requires purchasing a different type of cable. >>

ThunderBolt cables should meet those specs as well, but are not a requirement. Be sure to limit length to ONE meter or less for USB-C displays.

For genuine ThunderBolt displays, their transmit speeds are TWICE as fast, and their length limit is 0.5 meter, maximum.

The Thunderbolt cable did not fix my external monitor issues. Spend a good amount of time with Apple support, going all the way to reinstalling the OS.

Diving deeper into my monitor, there are reports online that my monitor model can have issues with the USB-C port on the back. It's very odd the timing to line up perfectly with the Tahoe update, but the USB-C/Thunderbolt driven monitor will not work now. If I use an HDMI cable to Thunderbolt, the monitor acts normally, but the cable does not supply power.

So, for a solution, I will need to plug in 2 cables to the MacBook and travel to and from work with a power cable. Not a big issue, just not as expected when it worked fine before Tahoe.

I had tried all the options like

1. Changing the cable
2. Booting in Safe mode
3. Removing the display preferences file

Nothing worked.

For whatever reason it maybe, the thing that worked for me was

1. On my monitor, I switched the HDMI port version from 2+ to 1.4
2. This immediately made Mac to detect my monitor, but showed only 30Hz
3. I switched the HDMI version on my display back to 2+ and it still works.
4. I updated the frame rate to 60Hz, no issues.

The Mac does not rely on Windows-like side-loaded "Drivers" which are actually packages of resolutions and settings for a specific display. Instead, it goes straight to the immutable source -- it asks the display itself.

To get a Mac display to become active, you need the Mac to query the display, and the display to answer with its name and capabilities. Otherwise, the display will not be shown as present, and no data will be sent to the display. "No signal detected" is generated by the DISPLAY, not by the Mac.

This query is only sent at certain times:

• at startup

• at wake from sleep — so momentarily sleeping and waking your Mac may work

• at insertion of the Mac-end of the display-cable, provided everything on that cable is ready-to-go

• hold the Option key while you click on the (Detect Display) button that will appear in Displays preferences (from another display)

so try doing some of those things and see if the display comes alive.

<< Now only one monitor will connect unless I switch the other one off and on again. >>

Powering off and on displays may not be the best way to troubleshoot, because of the way MacOS detects displays.

The Mac does not rely on Windows-like side-loaded "Drivers" which are actually packages of resolutions and settings for a specific display. Instead, it goes straight to the immutable source -- it asks the display itself.

To get a Mac display to become active, you need the Mac to query the display, and the display to answer with its name and capabilities. Otherwise, the display will not be shown as present, and no data will be sent to the display. "No signal detected" is generated by the DISPLAY, not by the Mac.

This query is only sent at certain times:

• at startup

• at wake from sleep — so momentarily sleeping and waking your Mac may work

• at insertion of the Mac-end of the display-cable, provided everything on that cable is ready-to-go

• hold the Option key while you click on the (Detect Display) button that will appear in Displays preferences (from another display)

so try doing some of those things and see if the display comes alive.

Adding my solution for the algorithm: Using a proper TB cable.

I was using a random USBC cable to connect my M4 MacBook Pro to a TB4 dock with two monitors. This worked fine before macOS 26, and currently still works with my Linux laptop.

Anyway, this morning my MacBook couldn't see more than one monitor at a time connected to the dock.

I switched to a proper TB4 cable between my MacBook and the dock and both of my screens were immediately detected.

Good Luck!

I had the same problem - MacBook Air OS 26.01 working OK with 2 monitors, docking station and 2 monitors. Then upgrade overnight to OS 26.1 - all stops.

I use AI to talk me through all sorts of fixes; reinstalling DL; safe mode starts, accessory permissions etc etc. Then after reading the end to end cable ideas I did what I should have done at the start - re booted the docking station. Hey Ho! All OK. Feeling stupid!

Hope this helps someone else.

Can’t believe it, but swapping the cable actually fixed it.

I had the exact same issue — after the OS26 update, my monitor just stopped working with the original type-C cable. Wouldn’t even charge the MacBook through it. Basically like the cable wasn’t plugged in at all.

Grabbed some random cable from a dead Thunderbolt hub I had lying around, and boom — the monitor came back to life!

Just to chime in with the same / similar problem.

I have my Mac Mini M4 hooked up to a RayCue M4 hub. Since upgrading to Tahoe the second display stopped working.

For different reasons I recently purchased the UGreen M4 dock with DisplayPort connector to replace the RayCue. Unfortunately that also doesn't send a video signal to my second display.

From work I have a cheap USB-C hub with HDMI-out. That doesn't send a signal to my second display.

But luckily I also have a cheap USB-C to HDMI / VGA / DVI dongle.

Guess what... that works, as long as it is connected directly to the M4. Moving it to another USB-port from one of the docks, there's no video-output.

To my guess video-output is for whatever reason disconnected when there a hub in between.

Unfortunately, this issue seems to have been around for years.

MacBook M1 don't recognize my external mo… - Apple Community

Here is another thread from 2021 about an M1 MacBook Air on Big Sur having a very similar external display detection problem. The workaround back then was also to remove WindowServer/display preference files.

Now, years later, users are still reporting similar external monitor detection or black-screen issues after macOS Tahoe upgrades, and the suggested workaround is again to delete com.apple.windowserver.displays*.plist / WindowServer preference files and restart.

This makes it look less like an isolated cable, monitor, or dock issue, and more like a long-standing macOS display configuration/cache problem.

It is extremely frustrating that across multiple generations of Apple Silicon Macs and multiple macOS releases, external display detection can still break in this way. Apple really needs to investigate and provide an official fix, not leave users relying on deleting preference files as a workaround.

I have the same issue with my docks. I have a WD19TB and a WD22TB4 dock, and I have the same issue on both of them. Plugging into the dock previously would give me access to two monitors, usb ports etc. (on M3 Max 14"). But now, the "first time" I plug in my dock into a specific port, it will work. But unplugging it and plugging it back in will result in no connections at all. (or trying on a new dock)

Additional symptoms are that the system info / thunderbolt section takes FOREVER to refresh.

Demonstration here: (before plugging into my one remaining "untested" port)

Result: Dock works (both monitors +USB KVM), but USB 4 text disappears from system info, Port reports nothing about device connection or anything (future connections will not work)

Restarting my computer restores all three ports to their original state (ie: I can connect each port one time again)

This is on both Tahoe MacOS 26 and 26.0.1