Why does my screen share freeze when I open another window?

Because you shared a single window rather than the whole display. When that window is covered or minimised, it can stop producing new frames, and the meeting client has nothing fresh to send. Instead of showing an error, it repeats the last frame it received. Your own monitor looks completely normal, which is why the freeze is almost always reported by someone else first.

Do viewers get any warning that my screen share is frozen?

Usually none at all. A held frame is a clean, sharp, correctly sized still image, not a blurry or pixelated one, because the encoder is happily sending a static picture. There is no spinner and no paused banner in most clients. Viewers assume you have simply stopped typing, and can sit watching a minutes old screen without suspecting anything.

Does minimising a shared window stop the screen share?

Effectively yes, on every platform worth assuming. A minimised window is no longer being composited, so there are no new pixels to capture. Depending on the client and the capture path you get a frozen last frame or a black rectangle. Switching to another virtual desktop with the Windows key, Ctrl and an arrow behaves the same way, because the shared window is no longer on screen.

Is covering the shared window as bad as minimising it?

It is less reliable but often survivable. Modern Windows window capture reads a per window surface kept by the desktop compositor, so a covered window frequently keeps updating for viewers. Older capture paths read what is actually drawn on screen, so occlusion produces a stale or partially wrong image. You cannot tell which path your client chose without testing it, so test rather than assume.

How do I share a window and still use other applications?

Put the shared window and the other application side by side with the Windows key and an arrow, or move the other application to a second monitor. If you genuinely need to alt tab through several apps, close what you do not want seen and share the entire display instead. If the content is a web page, sharing that browser tab is the most occlusion tolerant option.

Why did my share freeze for a few seconds with nothing covering it?

A Windows permission prompt is the usual answer. User Account Control runs on a separate secure desktop that no capture tool can read, so viewers get a held frame or a black screen for as long as the dialog sits on your monitor. Answering the prompt resumes the picture. A lock screen or screensaver produces the same short gap.

Screen Share Frozen When You Open Another Window: Why and Fix

Nothing crashed. You shared a single window instead of the whole display, then covered it or minimised it, and that window stopped producing new frames. The meeting client will not show an error for that, so it repeats the last frame it received. Viewers keep watching a sharp, correctly sized, completely stale picture, and on your own monitor everything looks perfect.

The part nobody tells you: a held frame looks healthy

People expect a broken video stream to look broken. Blocky, smeared, a spinner, a grey panel saying the connection dropped. A frozen window share looks like none of that. The encoder is being handed the same image over and over, which is the easiest thing in the world to compress, so it sends a crisp still frame using almost no bandwidth. Your connection quality indicator stays green. There is no paused banner, because most clients only show one when a presenter deliberately pauses the share, which is a different state entirely.

So the failure is silent at both ends. You see your real desktop. Your viewers see a screenshot from four minutes ago and assume you have stopped typing. The tell is almost always social rather than technical: someone eventually asks whether you are still on the same file, or asks a question about something you scrolled past long ago.

One detail sharpens the diagnosis. In most clients the mouse pointer is composited into the stream separately from the captured window, so viewers can sometimes still see your cursor moving over a picture that never changes. If a viewer reports a live cursor over dead content, that is a frozen source, not a network problem.

Covering and minimising are two different failures

They get lumped together, and they should not be. On Windows there are broadly two ways a client can grab one window. The modern path asks the desktop compositor for that window's own surface, which the system keeps updating whether or not the window is visible, so a covered window frequently keeps streaming fine. The older path effectively reads the pixels sitting on screen inside the window's rectangle, so anything on top of it either freezes the capture or bleeds into it.

Minimising defeats both. A minimised window is not being composited at all, so there is no live surface to read and no on screen rectangle to copy. Every capture path degrades to a held frame or a black box. Switching to another virtual desktop with the Windows key, Ctrl and an arrow does the same thing for the same reason, and catches people out constantly because it feels less drastic than minimising.

You cannot tell from the outside which path your client picked, and it can differ between two apps in the same meeting. Treat that as a reason to test rather than a reason to guess.

The sixty second test that tells you which one you have

Run this once, on the machine and the client you will actually use. It costs a minute and it settles the question permanently for that setup.

Put something visibly moving in the window you will share

A clock showing seconds is ideal. A page with a spinning loader, or a text file where you hold down a key, works too. A static document is useless here, because a frozen share of a static document is indistinguishable from a working one. This is the step people skip, and skipping it invalidates the whole test.

Join the same meeting from your phone, muted, speaker off

Watch the phone, not the local preview. Some clients build that preview from a different code path than the stream they send out, so a moving preview is not proof that anyone else is receiving motion. The phone is a real second viewer, which is exactly what you need.

Share the single window, then drag another window over half of it

Look at the phone for ten seconds. Seconds still ticking means your client is using the compositor path and mere overlap is safe. Frozen, or showing the covering window instead, means you are on the older path and anything on top of the shared window breaks the stream.

Minimise the shared window and count to ten

Expect the phone to freeze or go black. If it does, that is normal and not a bug you can file. Restore the window and note how long it takes for motion to resume, because that lag is what your viewers get every time you come back from another app.

Repeat the whole thing with the entire display shared

Cover, minimise and switch virtual desktop again. A full display share should survive all three, because it captures the output of the monitor rather than one window. What it will not survive is a lock screen or a Windows permission dialog, and now you know the difference between those two symptoms.

What each share mode does when something goes on top

Share mode	Another window covers it	You minimise it	What viewers see beyond the content
Single window, modern compositor capture	Usually keeps updating	Freezes or goes black	Only that window, even when it is buried
Single window, older on screen capture	Freezes, or leaks the covering window	Freezes or goes black	Whatever happens to sit in that rectangle
Entire display	Fine, but the covering window is now visible	Fine, and viewers watch you minimise it	Everything on that monitor, notifications included
Browser tab, Chrome or Edge	Generally keeps updating	Generally keeps updating	Only the page area of that one tab

Two honest caveats on that table. Tab sharing is the most occlusion tolerant option, but browsers throttle timers and animation in background tabs to save power, so a page that animates on a clock of its own may stop moving even though the capture is working fine, which produces the same freeze complaint from a completely different cause. And on a laptop running on battery, aggressive power saving can slow redraws in a background window enough that viewers report stutter rather than a clean freeze. Both are worth knowing before you blame the meeting client.

What to do instead

Stop minimising the shared window. This one habit causes most of these reports. Snap it with the Windows key and the left or right arrow, put the other app in the other half, and both stay composited.
Give the second monitor everything you are not sharing. Shared window on monitor one, notes and chat and the meeting client itself on monitor two. Nothing ever overlaps the shared window, so the question never comes up.
If you must move between several apps, share the entire display. Close what you do not want seen, silence notifications first, and accept that everything on that monitor is now public.
Share the tab when the content is a web page. Coding pads, dashboards and documents all qualify, and tab capture is far less bothered by what sits in front of it.
Leave a heartbeat in the shared window. A visible clock, a blinking cursor, anything that moves. It converts a silent failure into an obvious one for anyone watching.
Ask a better question. "Can you see my screen?" gets a yes from someone staring at a stale frame. "Is my cursor moving, and what does the clock say?" gets a real answer.
When in doubt, restart the share. Stop sharing, share again, pick the window that is actually in front of you now. Five seconds, and it beats ten minutes of presenting to a photograph.

Things that look identical but are not this

A short freeze with nothing covering the window is usually a Windows permission prompt. User Account Control draws on a separate secure desktop that no capture tool can read, so the stream holds its last frame until you answer the dialog, then resumes. A lock screen, a screensaver or a fast user switch does the same. A genuine network problem looks different: it degrades before it stops, goes blocky or smeary, then jumps forward to catch up, whereas a source freeze is pin sharp right up to the moment it stops and never catches up when it returns. And if a particular window arrives as a black rectangle rather than a stale image, that is a separate family of causes including protected video playback and deliberate capture exclusion, which other pages in this section cover.

Does a floating overlay cause this?

Not by itself. An overlay is just another window sitting on top, so on the older capture path it belongs in the occlusion category above, and on the compositor path it is irrelevant. The freeze comes from the shared window not producing frames, not from something being drawn over it. The overlay used by OfferPilot AI is marked as excluded from capture at the operating system level, so it never reaches Zoom, Teams, Meet, OBS or a screenshot in the first place, while staying readable on your own monitor. Worth stating plainly: that exclusion covers software asking Windows for the screen, and nothing else. It does nothing about a webcam, a phone camera pointed at your desk, a lockdown browser, eye tracking, or a person sitting in the room with you.

Where this page, and our product, stop being useful

If you landed here with a work presentation frozen right now, take the fix and go: snap the windows side by side, or restart the share on the entire display. There is nothing here for you to install. OfferPilot AI is an interview assistant for Windows 10 and 11, not a screen sharing repair tool, and it will not make a minimised window stream. Everything above is Windows specific as well. macOS and Linux have their own capture models and their own quirks, and guessing at them for you would be worse than saying so. If you are sitting a proctored assessment under rules you agreed to, none of this is a workaround for those rules. Ask the proctor before you change what you are sharing.

The compressed version, worth remembering the next time someone says the screen looks stuck. Sharing one window means only that window is being read. Covering it might be survivable. Minimising it never is. And whichever one happens, the platform holds the last good frame and tells nobody, so build the habit of never letting the shared window leave the screen.

Why your screen share freezes when you open another window