Windows 10 Pro local machine crash on doing a TeamViewer session

[Naki]

Issue: When I try to run 3-4 VMs on VMware Workstation, then connect remotely via TeamViewer to that PC with those VMs on it running, in a few seconds (under 1-2 minutes), the local PC - the one with VMware not installed or running on it - will invariably BSOD.

I contacted TeamViewer tech support on this, but they were unable to help, what they suggested did not help any. Is this a known issue?
Is it a VMware Workstation, or Windows 10 issue, please?

The BSOD code and system file that failed are:

Stop Code: PAGE_FAULT_IN_NONPAGED_AREA

What failed: win32kfull.sys

Can you do something to fix this? Or can Microsoft do it, and in what way should I report this to them, if so?

Please note I can provide the crash logs (minidump files) if necessary.

Thanks in advance for any comments or suggestions.

[Scillonian]

BSOD is too generic. On the BSOD screen there should be an error code such as '0x000000E2 MANUALLY_INITIATED_CRASH'. What is it on your BSOD?

[Naki]

It is this:

Stop Code: PAGE_FAULT_IN_NONPAGED_AREA

What failed: win32kfull.sys

[Scillonian]

The BSOD is the result of win32kfull.sys trying to read from or write to an invalid system memory location. To find out exactly what cause win32kfull.sys to do this you will need the help of someone who can decode the crash dump file.

At a more general level this BSOD is often the result of the recent installation of faulty hardware and/or drivers. Other causes include faulty RAM, antivirus/malware services and NTFS volume corruption. Check to see if any drivers have been updated recently — graphics and network interface being the most likely on this situation.

Try using another method (RDP, VNC) to connect to the remote host running Workstation. This may help to isolate the problem to TeamViewer or the local machine itself.

[wila]

Hi,

the local PC - the one with VMware not installed or running on it - will invariably BSOD.

I'm failing to see how it can be a VMware issue if the PC that crashes has not even a VMware product installed.

It can be due to a number of other issues though,  it might be a hardware or driver fault on your local PC.

This is what MS has to say about the PAGE_FAULT_IN_NONPAGED_AREA error:

PAGE_FAULT_IN_NONPAGED_AREA 

Explanation:

This Stop message occurs when requested data is not found in memory. The system generates a fault, which normally indicates that the system looks for data in the paging file. In this circumstance, however, the missing data is identified as being located within an area of memory that cannot be paged out to disk. The system faults, but cannot find, the data and is unable to recover. Faulty hardware, a buggy system service, antivirus software, and a corrupted NTFS volume can all generate this type of error.

The link above has more details.

Yes it could be teamviewer, but there can be several other reasons as you can see in the quoted article.

Things I would verify:

- has the PC enough free disk space on the drive that holds your paging file (by default C: drive)

- is your disk without faults?

- check your video driver to see if there's a newer one and install that.

- verify your RAM, run a diagnostics tool to verify it, such as memtest86 (my preferred tool for that) but it seems Windows also has something built in see http://www.pcadvisor.co.uk/how-to/pc-upgrades/how-check-for-bad-ram-modules-in-your-pc-3432631/ for more details.

--

Wil

[Naki]

1) Not drivers in any way, not anything in local machine other than TeamViewer.

Local machine has a Radeon R6 260X videocard, and issue is since 5-6 months. Many new video drivers have been installed during that time, no change.

One of the remote machines has a R9 290 card, the other has a GeForce GTX 670 card. Similarly to above, these 2 machines have also been updated with new video drivers multiple times, no change.

2) My RAM is fine, but will double check again. No viruses or bad/buggy antivirus here. I use Avira Free, which has its quirks, but works fine otherwise.

LAN driver has nothing to do with this.

3) Using VMware Workstation locally is fine. Using RDP (Remote Desktop Connection) is also fine, but I like TeamViewer better, as I do not have a static public IP address on all PCs.

I live in 2 locations, so my use case is trying to access my main PC (and other PCs) remotely.

Local machine(s) has/have no problems. I am using VMware Workstation on 2 machines.

ANY machine that connects to one of the 2 machines with VMware Workstation running, and 3-4 VMs open/active, will crash with a BSOD.

This happens no matter what is running or not running on the local machine. Remote machine is not affected in any way when the local one BSODs.

NO machine crashes when used locally, no machine crashes if connected via TeamViewer and remote PC does not have VMware Workstation running, or has it running but no VMs are active.

---> Thus, it seems the issue is with VMware+TeamViewer (possibly Windows 10 too, have no older OS to try.)

EDIT: Cancel that, have a Windows 7 laptop too, belongs to my woman here. Can try on that and report if that one BSODs too...

[Naki]

@wila, you are clearly wrong, see below why...

See my previous reply too.

LOCAL PCs never crash or BSOD, whatever I do on them, unless I use TeamViewer to connect to a remote PC (or even one in my local LAN/same room) with VMware Workstation running on it, and some VMs open.

IF I use any PC with VMware Workstation locally, there are no BSODs, no matter what I do with VMware or outside it.

IF I use one of my PCs with no VMware on it, there are no BSODs too.

If I use RDP to connect instead of TeamViewer, there is no BSOD too.

IF I connect to the remote PC via TeamViewer, but VMware is not running on remote PC, all is fine. Even if VMware is running, if no VMs are open, all is fine too.

Disk space is fine - 13 GB free on this PC, over 30 GB on 2nd, over 100 GB on main PC. On the PC with 13 GB free, the Page file is not on drive C:, I have moved it elsewhere.

I am using SSDs on all my machines - the SSDs are in fine shape. Also using at least one HDD on all PCs, all fine.

RE video drivers, as I replied to the other poster above, multiple driver versions have been installed on all PCs, no change - same BSODs for several months now.

RE RAM - will test, but as issue happens on several PCs, I think this is a moot point - my RAM cannot be faulty on 3-4 PCs, this is exceedingly unlikely.

I am checking out other options, such as other Remote access software, but if I can get TeamViewer working, it will be best for me.

[wila]

Very strange.

So your claim is that remote host + VMware workstation with VMs running and then connecting with teamviewer WILL crash the local machine every time.

Reproducable with several local machines.

Have you considered installing teamviewer on the VMs that you are trying to connect towards?

I understand that isn't ideal, but perhaps somewhere in the algorithm of teamviewer it gets confused because you are looking at virtual machine consoles which are itself using a form of VNC for the display/mouse/keyboard interface at that remote host.

--

Wil

[Scillonian]

‌Are you using the desktop or UWP (aka Metro/Modern/Windows Store) version of TeamViewer on Windows 10? Try the other version and see if that crashes too.

[dariusd]

I agree with the advice given by the other posters in this thread: It's a driver or OS problem.  If there is no VMware software running on the local PC, there is no way we could directly cause it to crash.  A BSOD on a system always means that there is a defect in that system's hardware, its OS kernel or its device drivers -- if those components are operating correctly, it is impossible for any application (local or remote) to trigger a BSOD.

What is possible, however, is that TeamViewer could be forwarding something from the remote system to the local system in a way that triggers the local PC to crash due to a driver bug on the local system.  Here are a few ideas to try to narrow down possible causes:

• Try disabling 3D acceleration in all the virtual machines running on the remote system: VM > Settings... > Display, and unselect Accelerate 3D graphics.  If the problem goes away, the problem is almost certainly your local system's display drivers.  Even if you have updated them in the past, that does not mean that the vendor should have fixed the problem you are encountering -- they might not be even aware of the problem.
• Try removing (or disconnecting) any sound cards in all the virtual machines running on the remote system: VM > Settings... > Sound Card, then either choose the Remove button if you don't need sound, or unselect Connected and/or Connect at power on.  Likewise, if the problem goes away, the problem is almost certainly your local system's sound/audio drivers.

I haven't used TeamViewer before, but you could also see if there is a way to disable some of its features for troubleshooting purposes.  Most likely candidates would be Audio forwarding, USB forwarding (if it is supported by TeamViewer... ?), File transfer/sharing, Clipboard sharing, Remote printing (?).

Cheers,

--

Darius

[oldsk00l]

Hi,

We have exactly the same problem with only one machine. But this machine is not virtual - it is a physical machine with Win 10 x64 Pro (newest updates) AND Teamviewer...

It is one of our management PCs with vSphere installed and if we are connected within 1-2 hours, we get a bluescreen from every machine connected.

We are using Teamviewer 11 but had the same problem with Windows 7 x64 Pro and Teamviewer 10 before. The system was not updated to Win 10 - it were a fresh and clean new installation.

There is no software on this machine except vSphere, FileZilla, WinSCP and Teamviewer.

So i think it might be a hardware problem / incompatibility.

[damemate]

I know this is an old thread, but I've found some threads with the vSphere web client causing this problem.

I'm running W8, TV12, and connecting to a W10 running Chrome with the vSphere client on it (6.5)

Sometimes I'll get a BSOD after working 5' or less, sometimes more, but It's always when I'm interacting with the vSphere website.

BSOD details are exactly like OP. I think this is related to Teamviewer, I haven't used another way of accessing it for this particular client, I do work with other clients using Screenconnect and never had a BSOD.

[guruerror]

I have the same issue as the OP describes. 

Using a Windows 10 Pro machine to connection to another Windows 10 Pro machine using TeamViewer 12.  The remote machine has VMPlayer installed; after a few minutes of interaction with any VM on the remote machine my local machine will BSOD:

Stop Code: PAGE_FAULT_IN_NONPAGED_AREA

What failed: win32kfull.sys

Caused by: ntoskrnl.exe

BSOD occurs after approximately 1-2 minutes of interaction with the VM without fail.  If a VM is NOT open and running TeamViewer will run flawlessly for hours.

[Gweeds]

Hi Guys,

I have been having this issue as well and had it on multiple PC's so drivers, hardware etc are out of the question.  The only common part is Teamviewer.

What I have found though, in my case, if I full-screen the TV session I can stay connected.  However windowed will always blue-screen my PC.

[guruerror]

That's a nice catch Gweeds.  I'll give it a try the next time I'm in the office. 

[Studiosoundsrad]

Very similar issue with windows 10 over teamviewer running VMware which works fine until i run chrome or a browser on the vm at which point the vms display freezes and won’t update again, the vm itself actually keeps running fine however it’s of no use when you can’t access it or see anything,

did you find a solution to yours in the end?

[wila]

Hi StudioSoundsradio,

Try turning off hardware acceleration in google chrome and see if that helps.

http://www.techadvisor.co.uk/how-to/internet/how-turn-off-gpu-hardware-acceleration-in-google-chrome...

--

Wil

[Studiosoundsrad]

Thanks for the quick reply, your answer pointed us in the right direction, we couldn’t access chrome settings over team viewer on VMware as anytime chrome was opened it would freeze, we turned off 3D acceleration in VMware just to see if that would help and now everything works perfectly

massive thanks as it was driving us crazy trying to do some things remotely

[guruerror]

I believe I've tracked this problem back a USB pass-through issue.

If I edit the .vmx and change usb.present = "TRUE"  to usb.present = "FALSE" my local workstation stays stable and does not BSOD.