This post is more than 5 years old
9 Posts
0
13598
March 8th, 2011 15:00
Gray \ Blue Screen on Log off
Hello everyone,
I need help. Bad.
This is my enviroment. 3 Dell Poweredge 2900 servers running Windows 2003 SP2 Datacenter. Installed is Parallels Virtuozzo Containers 4.6 and for Quest we have 1 SSL GW, 1 CB, and the version installed is 7.2. The issue I have is that when users go to log off everything starts to log off but then windows box that says "Logging off" never shows and it just sits at the background with no icons and Quest vWorkspace still shows the user logged in, not disconnected. If you try to log back into the computer it just sits at the same background with no icons.
What I have done to troubleshoot is to install the old PNTools back to 7.1.0.356 and try it. Still no change. Looked at the running processes when it logs off and the only things running for that container are winlogon.exe and csrss.exe. If you use procmon and kill the winlogon process for that container it logs the session off, or actually just kills the session all together and the user can log back in and runs fine. I can also log the computer off through vWorkspace mgmt console. The third way that I have had to train users on is to use the vWorkspace icon on the laptop and go to OPEN SESSIONS then click the log off button and it properly logs the computer off. I have tried to debug the winlogon process on the computer but if you set the winlogon for debugging you will no longer be able to access the computer because of the way parallels works.
If I RDP straight to the computer and log off it works fine everytime, so this leads me to believe it is a quest vWorkspace issue for sure and not a parallels issue. I have been trying to get this fixed ever since we upgraded to 7.2 about 2 months ago. Nothing shows in the event log for the computers or the server nodes. I've opened a ticket with quest and have gotten no where so far with them and I also have a ticket opened with Parallels and verified it works fine there. We made a plain jane container in parallels and tested log offs and it works fine with RDP then installed PN Tools 7.2 and then could no longer log off with the vWorkspace client but RDP still worked. I've taken all the antivirus off the server and ripped that down as far as I could and still make it useable to users. I have disabled all extra resource mappings in quest on the server and the client itself including the EOP and it has not made a difference.
If anyone can lead me down a new path for help that would be awesome. Thank you.
- Jeff
jeffhealy
9 Posts
1
July 15th, 2011 22:00
Richard,
I have felt your pain for so long with this issue and eventually support seemed to just give up. Ian the support rep was a great guy but he never found a resolution.
I like you have been through everything and ripped the container down to nothing. I tweaked the auto-log offs. Ran through debugs to catch what was not closing on log off and nothing worked. People would call me non-stop every day with the blue screen hang. I spent most of my day in the management software logging people off. Those that I could teach to go to the systray and get session properties from the vworkspace icon and click log off could fix themselves. This cut down some support calls but I was still flooded. I even built a new broker, new parallels server, new container all from scratch and minimal updates tracking everything I installed and it made no difference what so ever.
I have since upgraded my enviroment to 7.2 MR1 and things are working correctly now. I had to go through and updat the broker, gateway, and ALL the clients on every workstation. Plus update the PN Tools to .461 on all the containers. This seems to fix the blue - gray screen hang on log out. It also fixed my usb connectivity issues that we have with USB signature pads. As Ian and I expected it had to do with the USB hooks that PN Tools installs.
Let me know if you get a chance to upgrade to 7.2 MR1 and see if it helps you out also.
Jeff
DELL-Marc Z
30 Posts
0
March 8th, 2011 16:00
Sounds like a potential Windows Logon Notification Package(WNP) issue. Try this to determine whether a vWorkspace WNP is causing the problem:
1. Open registry editor and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
2. You will see a number of keys that start with 'PN'. Try going into the first 'PN' key (most likely PNFMMR) and rename the value DLLName to DLLName2. This effectively removes the PNFMMR WNP from the system.
3. Restart the container and try your logoff test.
4. If the problem still occurs, repeat for the next 'PN' WNP until you have removed all of them.
If you find that one of the 'PN' WNPs is causing the problem, it will definitely help us define the issue and potentially suggest a solution.
Of course, after this test you should rename all the DLLName2 values back to DLLName.
jeffhealy
9 Posts
0
March 9th, 2011 02:00
Marc,
Thank you for responding and trying to assist me in my soul crushing issue. I have gone through the registry and disabled all the PN keys that you talk about by renaming the dll in the value to name.dll.old rebooted after each one and tried and still could not log off. Tried it on two different servers with two different containers of parallels and nothing changed.
Do you have another good suggestion for me?
DELL-Andrew W1
378 Posts
0
March 23rd, 2011 16:00
Hi Jeff,
Do you still have this issue?
If so,
1. Open vWorkspace Management Console
2. Navigate down through Locations | Desktops | to your Desktop Group
3. Right click on your Desktop Group and select properties
4. Click "Session Auto-Logoff"
5. Add csrss.exe to the list
6. With this set, try logging off again to see if it is fixed.
7. If it still isn't fixed, add winlogon.exe to the list.
Thanks, Andrew
jeffhealy
9 Posts
0
March 28th, 2011 13:00
I have added that to the list of all the other exe's we have tried to auto-log off and it does not work. Not sure what else to do for this issue. I can burn down all the servers and recreate everything but to be honest if I am going to go that far then I might as well get rid of the setup all together and find something more stable to begin with.
DELL-Andrew W1
378 Posts
0
March 28th, 2011 14:00
Hello Jeff,
This should still be easy to fix.
Take a look at Autoendtasks and waittokillapptimeout.
Autoendtasks can be set in the default reg, here:
HKEY_USERS\.DEFAULT\Control Panel\Desktop
Create a DWORD value called
Autoendtasks
Give it a value of 1.
To test just for your user, do the same here instead:
HKCU\Control Panel\Desktop
Create a DWORD value called
Autoendtasks
Give it a value of 1.
Then,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout
Change this to a smaller number, such as 1000.
Thanks, Andrew.
jeffhealy
9 Posts
0
April 5th, 2011 02:00
I have tried to adjust these settings and it still does not work. I am trying this on a couple different containers between the 3 servers to make sure its not just a bad node that is the issue.
I just don't understand why it works fine in RDP and also if I open the vworkspace client from the systray the go to Session Properties and click the log off button from there it works fine. You see the session start to save settings and do a proper log off.
jeffhealy
9 Posts
0
April 5th, 2011 03:00
Does anyone think that this hotfix may work? Not sure if it is approved by Parallels but seems like it might be a possible fix.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;935926
richard10
13 Posts
0
July 15th, 2011 21:00
Hi Jeff,
Have been having a very similar issue to yourself except my issueis a blue screen on log off (not BSOD)
We use vmware with v7.1MR1 brokers, thin clients being wtos.
So far i have done a multiple number of actions including thefollowing, which have been sent to me via Andrew who has my currentsupport case.
So far the problem I was able to recreate consistently theprevious week I have now since been able to recreate though stillhave calls arriving on my desk...(peak of 80 a day)
A way i have found of getting things down to a more manageablelevel is to use the "reset on log-off", though this may ormay not be acceptable from a storage viewpoint. And in our case meansthe machine isn't available for approx 4-5 minutes. A slight userinconvenience when they aren't persistent.
This week..i have tried with a different thin client device, wherethe same problem occurred.
I have since now disabled the anti virus on the 'documents andsettings' folder, which has stopped our 1 particularly vocal userfrom calling me with a problem, this has worked for them.
I'm now trialling the same AV exceptions on a site with thehighest number of calls generated. If this is successful then it willbe a case of file/folder elimination on the documents and settingsfolders and then widening this policy. Though the deployment isn't ahuge deployment (1300+ machines) the machines themselves are used forapplications of high importance.
Hope that helps, and I'll update this thread with my findings next week. Where i then have my next fun task of working out how from the vworkspace console i can modify an application colour depth and bandwidth requirements. As yet i've not found how.
Cheers
Richard
ps Andrew i need to keep the call open if possible.
richard10
13 Posts
0
July 18th, 2011 19:00
Thank you Jeff.
Your answer was what i was edging closer to in my own mind.
Have had a chat with management today, I think they are now convinced an upgrade to 7.2MR1 is due sooner rather than later..
Will report back once its done, hopefully with the same results as yourself.
Thanks once again,
Richard
jeffhealy
9 Posts
0
July 28th, 2011 14:00
Any luck on your deployment?
- Jeff
richard10
13 Posts
0
July 28th, 2011 14:00
Have (finally) got approval for the upgrade, running through a test upgrade hopefully tomorrow. Then its whenever i can get the change pushed through....
Wheels turn very slowly sometimes...
Am marching through with PNtools upgrades and re-packaging the 7.2 AppPortal client though so this should be finished by the time its authorised.
Cheers
Richard
jeffhealy
9 Posts
0
October 4th, 2011 21:00
Well after so long of running just fine guess what is back. I did our monthly maintenance last month and since then the reports of the log off hangs are back in effect. I will peel the updates off the servers this coming sunday and see which one broke it. I'm am starting to loath this software.