Out of Memory Errors????
Hello all, I currently have 100+ Z90S7 TC's deployed and I have started running into an issue where on logon every day 3-6 people will call because they get an out of memory error and the system reboots. Now this doesn't just happen once but up to three times in a row before they can log on. Here is my set up. The user only use VMview to connect to a VM. Nothing else is run on the TC. I have streamlined the settings for the vmview client to reduce the audio bit rate, lower the client side cache and reduse the screen res. The TC's themselves have the write filter enabled and have the ramdisk set to 128megs. I am at a loss as to why this happening and any ideas would be welcomed. Also I did see one other error that pointed to the settings.ini file in use. This is starting to heat up with more people having the issue.
Couple quick thoughts:
The RamDisk utilizes system RAM, so the bigger the RamDisk, the less available system RAM available for use by Windows; I would make that as small as possible, 100MB should be plenty.
My guess is that you have a 4GB/2GB unit; due to the way that the VMWare View client uses RAM for client side caching after 5.0, it can use up more ram than is available, and since there is no Page file to absorb the extra need, Windows reboots.
To fix the View client ram usage, take a look at the following link: http://pubs.vmware.com/view-50/index...946BF1D47.html
Thank you for the ideas, It seems I have a double post going on and I apologize for that. I will close the other, I did figure out exactly why it is bouncing lastnight as I was trying to apply some changes. the Write filter cache was at 105%. I have this set to 128meg. SO It seems that when the TC reboots the Cache is getting filled up fast. I noted this only happens when logging in as a domain user. If I log in as the local admin it is fine. So a little more looking and I see a lot of event log lines when I run the "fbwfmgr /displayconfig". Seems that hte GPO processing in association with the event log lines are what is using up a large part of my cache. So Changed some settings. I changed the Ramdisk to 128meg and upped the Write Filter cache to 196meg. seems most machines run around 53% of the write filter now. But I still had an issues with one user this am. Seems that when the write filter fills up it take mutiple reboots to clear it. I saw this last night when I was working hat 3 reboots to get the write filter totally cleared, or is it that the third time I logged in the policy processing ran at a delay? I am still trying to figure oyut a fix.
If all you are doing is launching a View connection from the client, then why put it on the domain? Unless you have some need for local access to file resources or the like, the domain, and especially group policies just complicate the client uncessarily. However, if you need it on the domain for some reason, then try putting them in their own OU, then block all inheritance and only apply the policies that you need. y
Additionally, are you using roaming profiles on the client? because without quotas that can eat up FBWF cache quickly. Speaking of the FBWF, you can use the command line fbwfmgr /overlaydetail to find out what file/folder is using up all the space in the cache, then you can try to move that from C:\blahblah to Z:\ which is the actual RamDisk on the clilent.
I apologize for the rambling