|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
This is something that's getting increasingly reported in several forums. Among them are the Firefox Q&A forum, and some of the deeper tech Domino ones. Switching between applications -- particularly Firefox along with either Notes 8, DDE, Photoshop, Visual Studio, or other highly graphical applications -- seems to produce screen redraw problems after a while. The screen only partly re-draws, leaving the application that was last up "ghosted" on the screen.
I've been searching and reading and testing, and one of the most common threads is people using multiple monitors. That threw me for a while, because you'd think it has to do with a driver conflict. Its not that at all. People with multiple monitors tend to run multiple complex programs at the same time. Thus the commonality of the symptoms.
People reporting on this problem say "when I shut down 'x' it gets better" -- then a day later say "nope, that wasn't it." That's because no one thing is causing the problem. Its the combination of everything that is causing problems.
When you next see this happening, bring up your windows Task Manager (crtrl-shift-escape) and scroll to the column marked "GDI Objects". You'll find that there are a LOT of them. You can click the column header to sort and see that Firefox, Notes2.exe, nlNotes, and so on are using a lot of them.
I believe the reason for the ghosting is because you're running out of these handles. If that's true, the following fix should help:
NOTE: Try this at your own risk. If it works, let me know. If you destroy your system, don't tell me about it. If you try this and break something, you own all the pieces. This is a patch to try IN TEST ONLY and on NON PRODUCTION data.
1. Back up your registry files. If you don't know how to do this, you shouldn't go any further. This fix is over your head.
2. Edit your registry via "regedit" to change the following settings:
In: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\Session Manager\SubSystems\Windows
Change the value from:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=2048,8192,1024 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
In: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota
Change the value to: 16384 * Do not exceed this value, and make sure you enter this in Decimal
In: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota
Change the value to: 18000 * Do not exceed this value, and make sure you enter this in Decimal
3. Reboot your system, and keep your fingers crossed.
I'd like to hear from your here, if you're having this problem -- and also if it (a) worked, (b) didn't work, or (c) scared you too much to try.
Please wait while your document is saved.
around the idea that with more memory, more code running, there is going to
need to be some give somewhere. This looks to be a brilliant approach.
I do plan to try this at home as soon as possible. I don't run multiple
monitors there, but it's common for me to run FF along with Notes 802 and
sometimes also Paint.NET. All told, some pretty intense graphic usage. More
handles should definitely help. I wonder if this fix also provides more memory
for pointers to the handles. That would be the next thing, I think, in line to
run into issues. (As I'm typing this comment I can't review the solution again
to see any hint of that in your posting :-)