Windows Kicked out of 'true' full screen - by XBMC itself?

cdldt · 2012-04-08 18:29

Recently I began to notice XBMC getting kicked out of full screen mode (gets minimized to the taskbar) when it was set to use true full screen, rather than full screen window. I am aware that this is due to a Windows issue with focus-stealing applications (thanks for "fixing" that in Windows 7, Microsoft Confused

).

I did some testing with the WinFocusMon utility and Process Monitor, hoping to discover which application was stealing focus. Unfortunately, WinFocusMon reported it to have been caused by XBMC itself and the PID in Process Monitor supported that.

Is this a red herring? I see that Google Updater ran around 15-20 seconds before losing focus, but then again, it appears to run quite often without stealing focus, plus its activity stopped 10 seconds or so before. There was nothing else in Process Monitor other than XBMC itself.

Please forgive my ignorance, but are XBMC skins able to launch a separate window in any way?

jack0w · 2012-04-09 17:27

I had a similar problem, see my solution here - http://forum.xbmc.org/showthread.php?tid=127983

If disabling those two processes from startup doesn't solve it for you try disabling all startup items (excluding XBMC) and see if the problem continues.

If it does, try disabling non-Microsoft services and see if that helps.

All of these adjustments can be made from either the services or startup tab of msconfig.

Hope this helps.

**kricker** · 2012-04-09 17:47

Turn on debug logging. Then grab a log from when that happens again and scan thru it. I believe a dev mentioned that XBMC supposedly logs what is stealing focus.

**jhsrennie** · 2012-04-10 19:06

Enable debug logging from System settings, System, Debugging, and restart XBMC and wait for something to steal the focus.

Open the debug log by pressing Windows-R and in the Run dialog type:

"%appdata%\xbmc\xbmc.log"

(including the quotes). Click OK and the log should open in Notepad. Copy and paste the log into http://pastebin.com/ and post the link it gives you here.

If you want to look at the log yourself look for lines like:

Code:

DEBUG: CWinEventsWin32::WndProc: Focus switched to process C:\Windows\System32\notepad.exe

This is from my log when I switched the focus to Notepad.

JR

cdldt · 2012-04-10 19:25

Thanks for the replies.

I enabled debug logging yesterday and XBMC didn't lose focus even after several hours - typical! Smile

Sod's law dictates that if I didn't have debug logging enabled it would have lost focus Smile

I'll keep debug enabled with the hope of catching it.

cdldt · 2012-04-30 23:43

This is all that was logged when XBMC lost focus, with debugging enabled:

Code:

37:37 T:4824   DEBUG: Error: Requested setting (pvrplayback.signalquality) was not found.  It must be case-sensitive

38:40 T:4824   DEBUG: Previous line repeats 1559 times.

38:40 T:4824   DEBUG: CWinEventsWin32::WndProcWindow is inactive

38:40 T:4824   DEBUG: Error: Requested setting (pvrplayback.signalquality) was not found.  It must be case-sensitive

38:40 T:4824   DEBUG: CWinEventsWin32::WndProcWindow is inactive

38:40 T:4824   DEBUG: Error: Requested setting (pvrplayback.signalquality) was not found.  It must be case-sensitive

I don't get the "Focus switched to process" line at all.

Looking in the Windows 7 event viewer, there are the following entries from around that time period:

Code:

22:36:11 BITS started the C:\Users\Username\AppData\Local\Temp\{0C35B1DF-D451-463F-A85E-AC49FBFF72F0}-chrome_updater.exe transfer job that is associated with the http://cache.pack.google.com/edgedl/chrome/install/1025.168_1025.162/chrome_updater.exe URL.

22:37:25 BITS stopped transferring the C:\Users\Username\AppData\Local\Temp\{0C35B1DF-D451-463F-A85E-AC49FBFF72F0}-chrome_updater.exe transfer job that is associated with the http://cache.pack.google.com/edgedl/chrome/install/1025.168_1025.162/chrome_updater.exe URL. The status code is 0x0.

22:37:25 The transfer job is complete.

User: ComputerName\Username

Transfer job: C:\Users\Username\AppData\Local\Temp\{0C35B1DF-D451-463F-A85E-AC49FBFF72F0}-chrome_updater.exe

Job ID: {78f55723-c5aa-4aa0-b791-ab360c4998d4}

Owner: ComputerName\Username

File count: 1

22:37:26 The Application Experience service entered the running state.

22:38:16 Starting periodic policy processing for computer WORKGROUP\COMPUTERNAME$. 

Activity id: {a4be8230-ba89-4dcc-9392-2e5f26f53e27}

I wonder if Google Chrome Updater is causing this, even though it's known focus stealing was supposedly fixed ages ago.

**kricker** · 2012-05-01 02:32

That's doubtful. I have Chrome installed on all my PCs and the updater never causes XBMC to drop out of fullscreen. Some else recently though had a similar issue and it was caused by a service installed with TotalMedia Theatre 5 or PowerDVD. Check your windows services and look for anything non Windows essential.

**DDDamian** · 2012-05-01 03:09

That timing is too close to ignore - as kricker mentioned - check the windows services, especially for anything seemingly related to "Application Experience".

cdldt · 2012-05-01 19:17

Thanks for the replies.

Looking at this with less tired eyes, it seems that the Chrome updater had finished its task before XBMC lost focus, so maybe it wasn't to blame.

I had no idea what Application Experience does, but from Googling it is apparently a Microsoft service responsible for on the fly workarounds for problematic applications in Windows 7. Presumably this service itself is not the culprit, but whatever prompted it to start could be.

I suppose the next job is to end running processes one by one and see whether it stops the focus stealing. It's so infrequent though. I'm going to leave Process Monitor with process create and thread create filters enabled (hopefully it won't stop responding) along with the XBMC debug log.

Regarding the XBMC log - does the "CWinEventsWin32::WndProcWindow is inactive" line correspond to the exact moment it lost focus, or is it just doing a regular check of focus and logging if it's not?

**DDDamian** · 2012-05-01 19:53

That log entry will be virtually instantaneous when the XBMC window is re-activated, meaning whatever stole the focus has finished and returned control of the active window to Windows, and in turn XBMC.

kricker Team-XBMC QA Specialist Posts: 3,307 Joined: Apr 2004 Reputation: 16 Location: Knoxville, TN	2012-04-09 17:47 Post: #3 Turn on debug logging. Then grab a log from when that happens again and scan thru it. I believe a dev mentioned that XBMC supposedly logs what is stealing focus. Read this before using these builds. XBMC win32 SVN builds Changelog (This post was last modified: 2012-04-09 17:47 by kricker.)
	find quote

cdldt Junior Member Posts: 11 Joined: Jan 2010 Reputation: 0	2012-04-10 19:25 Post: #5 Thanks for the replies. I enabled debug logging yesterday and XBMC didn't lose focus even after several hours - typical! Sod's law dictates that if I didn't have debug logging enabled it would have lost focus I'll keep debug enabled with the hope of catching it. (This post was last modified: 2012-04-10 19:25 by cdldt.)
	find quote