Phylum
Enthusiast
Enthusiast

Windows 10 v1607 VDI vm3dmp.sys BSOD

Jump to solution

Yesterday I was suddenly disconnected from my Windows 10 v1607 VDI and when reconnecting was just seeing a black screen.

After about 1-2 minutes or so I was able to reconnect & noticed it had rebooted prompting me to check Event Log for gems:

The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000d1 (0xffffe0fe07a00000, 0x0000000000000002, 0x0000000000000000, 0xfffff80ee2d55760). A dump was saved in: C:\windows\MEMORY.DMP. Report Id: bf05cd81-5e7d-4190-93af-dab35bee3049.

The MEMORY.DMP suggests vm3dmp.sys was the faulting module (process: VMBlastW.exe).

Thought's on how best troubleshoot this further?

Environment:

  • ESXi 6.5.0, 4564106
  • Horizon View 7.2.0 build-5735293
  • VM: Windows 10 v1607 without GPU attached (2 vCPUs, 12GB)
  • Using Blast
  • USB auto connect enabled
  • Dual monitor setup with display scaling enabled
  • No writable volumes; No AppVolumes

The full details of the analysis are in the file attached to avoid 4 screens of text; happy to paste text if requested.

Te computer has rebooted from a bugcheck.  The bugcheck was: 0x000000d1 (0xffffe0fe07a00000, 0x0000000000000002, 0x0000000000000000, 0xfffff80ee2d55760). A dump was saved in: C:\windows\MEMORY.DMP. Report Id: bf05cd81-5e7d-4190-93af-dab35bee3049.

1 Solution

Accepted Solutions
Phylum
Enthusiast
Enthusiast

Thanks for the reply h3nkY​!

If you can, please share the specific internal KB article or bug report reference number so that I can relay that to our support team.

Because right now, the fix according to VMware Support is kind of a stinky pile of poo:

  1. I opened a case with VMware support
  2. The alleged fix is to upgrade to VMware Tools 10.2+ (It's fixed in 10.2.0)
  3. View Agent 7.2 isn't compatible with 10.2+ so we have to upgrade that
  4. If we upgrade just the Agent and not the infrastructure, we're not in a supportable situation.
  5. Thus we have to upgrade the infrastructure to be supported
  6. Once the infrastructure is upgraded, we can then:
    1. Remove existing View Agent 7.2
    2. Reboot
    3. Remove existing VMware Tools 10.1.x
    4. Reboot
    5. Install VMware Tools 10.2+
    6. Reboot
    7. Install View Agent 7.4
    8. Reboot

<rant>Thinking Ahead: Periodically the infrastructure (ESXi, Connection Servers etc) needs to be upgraded and that's fine.  However, I'm annoyed that the client upgrade process is so intrusive: It's unfortunate that, per VMWare support, when upgrading VMware Tools you must also remove the View Agent.  Seems silly to me - it should "just work".  You can probably eliminate 1 reboot but we're still talking 3 reboots.</rant>

I'm taking a slightly different approach:  I've upgraded a significant number of our VDI's to 1703 hoping that might help reduce the frequency of occurrences until we can get a real fix in place.  So far, those that have been upgraded have not been flagged for BSOD's.

View solution in original post

0 Kudos
16 Replies
h3nkY
VMware Employee
VMware Employee

I think you need to open support ticket with VMware. It's difficult to root cause without seeing full memory dump.

0 Kudos
pbaideme
Contributor
Contributor

Phylum,

Did you ever get this resolved?

This seems to have cropped up since the latest vmtools, between ver 11 to ver 13,

Thanks,

Phil

0 Kudos
jseide86
Enthusiast
Enthusiast

Pbaideme,

VMTools is currently at v10.1.15 if I'm not mistaken.

Do you mean Virtual Hardware version 11 through 13 ?

0 Kudos
pbaideme
Contributor
Contributor

Correct

0 Kudos
h3nkY
VMware Employee
VMware Employee

This issue has been being investigated by VMware engineering.

If you need immediate fix, I suggest to open support ticket with VMware.

0 Kudos
jin09
Contributor
Contributor

I had this exact issue.  The only fix is to use HW version 11.  ESXi 6.5 + HW 13 + Windows 10 1607 will not work.  The issue is video memory, I can't remember the exact number, but if you set the video memory in the VM configuration any number (ex: 128mb), the VM will actually only see 4KB (you can find the log in the ESXi server logs).  When you try to resize the screen, this is what caused the BSOD.  Usually  happens when you are reconnecting to the VDI and the screen size slightly changes. 

0 Kudos
Phylum
Enthusiast
Enthusiast

Curious: Is there an update on this?  Or a internal/external KB number?  Or a case I can reference when opening a new case?

0 Kudos
nettech1
Expert
Expert

There is a similar thread here going back to 2010, but someone posted a comment at the end of last year stating that it worked on Windows 10

[SOLVED] BSOD on vm3dmp.sys after installing VMWare Tools 7 on Windows 7

0 Kudos
Phylum
Enthusiast
Enthusiast

No pbaideme - we're still seeing this every now and then and it seems to happen mostly when reconnecting to the VDI but that's purely anecdotal.

We're in the process of upgrading these VDI's (full clones) to 1703 so we're hoping that might help.

0 Kudos
Phylum
Enthusiast
Enthusiast

This issue has been being investigated by VMware engineering.

Hey h3nkY​ - where did you get this information from?  How do you know it was being investigated by VMware at the time?  Did you ever get an update on this?

0 Kudos
Phylum
Enthusiast
Enthusiast

There is a similar thread here going back to 2010, but someone posted a comment at the end of last year stating that it worked on Windows 10

[SOLVED] BSOD on vm3dmp.sys after installing VMWare Tools 7 on Windows 7

I hear you but the fact that I'd have to do this across 90 VDI's is not ideal.  Plus, it should just work, and if not hopefully VMware can help us hone in on it.  For all we know it's some security software that's to blame.

0 Kudos
h3nkY
VMware Employee
VMware Employee

Hi Phylum

I got from VMware bug report.

It already has a fix for this issue.

Please contact your support channel to get immediate fix.

0 Kudos
BenFB
Virtuoso
Virtuoso

Was the fix a new Horizon Agent version? I'm trying to assess if they've since incorporated the fix in the latest release.

0 Kudos
Phylum
Enthusiast
Enthusiast

Thanks for the reply h3nkY​!

If you can, please share the specific internal KB article or bug report reference number so that I can relay that to our support team.

Because right now, the fix according to VMware Support is kind of a stinky pile of poo:

  1. I opened a case with VMware support
  2. The alleged fix is to upgrade to VMware Tools 10.2+ (It's fixed in 10.2.0)
  3. View Agent 7.2 isn't compatible with 10.2+ so we have to upgrade that
  4. If we upgrade just the Agent and not the infrastructure, we're not in a supportable situation.
  5. Thus we have to upgrade the infrastructure to be supported
  6. Once the infrastructure is upgraded, we can then:
    1. Remove existing View Agent 7.2
    2. Reboot
    3. Remove existing VMware Tools 10.1.x
    4. Reboot
    5. Install VMware Tools 10.2+
    6. Reboot
    7. Install View Agent 7.4
    8. Reboot

<rant>Thinking Ahead: Periodically the infrastructure (ESXi, Connection Servers etc) needs to be upgraded and that's fine.  However, I'm annoyed that the client upgrade process is so intrusive: It's unfortunate that, per VMWare support, when upgrading VMware Tools you must also remove the View Agent.  Seems silly to me - it should "just work".  You can probably eliminate 1 reboot but we're still talking 3 reboots.</rant>

I'm taking a slightly different approach:  I've upgraded a significant number of our VDI's to 1703 hoping that might help reduce the frequency of occurrences until we can get a real fix in place.  So far, those that have been upgraded have not been flagged for BSOD's.

0 Kudos
Phylum
Enthusiast
Enthusiast

Hey BenFB​ - Take a look at my previous reply for details

TL;DR: VMware Tools bug/defect is fixed in VMware Tools 10.2.0

0 Kudos
BenFB
Virtuoso
Virtuoso

Thanks! We have most of our parents upgraded to 10.2.0 and are now starting to upgrade to 10.2.5.