vmms.exe crashes at 5 minute intervals when a SCOM agent is running


  • Faulting application name: vmms.exe, version: 6.3.9600.18895, time stamp: 0x5a4b0852
    Faulting module name: vmms.exe, version: 6.3.9600.18895, time stamp: 0x5a4b0852
    Exception code: 0xc0000005
    Fault offset: 0x00000000007dc6a3
    Faulting process id: 0xf7c
    Faulting application start time: 0x01d3eb9ffaacc7f9
    Faulting application path: C:\Windows\system32\vmms.exe
    Faulting module path: C:\Windows\system32\vmms.exe
    Report Id: f1d4e018-5793-11e8-8139-0025902acf1f
    Faulting package full name:
    Faulting package-relative application ID:

    Within 1 second or so after the monitor/script in SCOM 'GetHyperVMeteringUsage.ps1' runs, vmms.exe crashes with the error above.


    lunes, 14 de mayo de 2018 16:53

Todas las respuestas

  • Hi,

    Which SCOM version? CU/Patch level?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    lunes, 14 de mayo de 2018 19:05
  • All are at SC 2016 CU5.  I ran windows and SC updates on all SC servers and clients.  The crash in vmms.exe persists.  The event correlates each time to gethypervmeteringusage.ps1.

    Event ID 1102 in the Operations Manager log.

    GetHyperVMeteringUsage.ps1 : HyperVMetering: Failed to reset VM Resource Metering for VM :

    Where can I find this monitor to override?  I'm not having any luck..



    jueves, 17 de mayo de 2018 13:09
  • Same problem, I have the same errors however mine crashes every 60 minutes.

    It means I can not do any large replications to the box. If the initial replication takes longer than 60 minutes it will fail and restart in an ever ending loop.
    • Editado Kirbies lunes, 11 de junio de 2018 21:43
    lunes, 11 de junio de 2018 21:42
  • I have for now disabled it as per this

    Get-VM * |  Disable-VMResourceMetering

    martes, 12 de junio de 2018 19:45
  • Few more details;

    I can cause a manual vmms.exe service crash on the replica server by running PS command

    measure-vm *

    I then used  process monitor to capture vmms.exe events from around when I knew it was going to crash.

    The last vmms.exe events before the crash are TCP receive and disconnect from the replica server to just one of the failover cluster servers.

    Looking at the operations manager event log on the failover cluster server confirms that the cluster server is firing off the gethypervmeteringusage.ps1

    When it does that every hour it also re-enables the disable resource metering on the replica server for the replicated server.

    So I have now run the command on both cluster servers and the replica server to disable metering.

    This is only a temporary fix to over come the problem and won't help anyone who needs metering.

    My cluster servers are 2016 and my replica is 2012 R2. Not sure if the issue is at 2012 R2 and an upgrade would fix it.

    miércoles, 13 de junio de 2018 11:19
  • Nice diagnostics.  My Hyper-V hosts are a mix of 2012R2 and 2016 but primary and replica Hyper-V hosts involved in this issue are 2012R2 and the server exhibiting this problem is 2012R2.  The SC management servers are all 2016.


    miércoles, 13 de junio de 2018 12:26
  • I set Get-VM * |  Disable-VMResourceMetering on the replica server and will check back.


    miércoles, 13 de junio de 2018 12:27
  • So far every 2016 cluster re-activates resource metering every hour which in turn kicks off the ps1 on the replica server and crashing vmms.

    I am going to stop being lazy, migrate servers off 2012 r2 tonight and install 2016. hopefully that will fix it.

    miércoles, 13 de junio de 2018 13:51
  • Crashing on the hour here after enabling the SCOM agent.  Trying UR5 Friday.


    miércoles, 13 de junio de 2018 21:08
  • I was on release 5 and didn't make a difference.

    It does look like the problem stems from SCOM and it pulling metering from a 2012 R2 replica in a 2016 cluster.

    Upgrading my replica to 2016 last night has solved the problem for me. As for now I can't do any more diagnostics as to why it was an issue. I can only imagine a problem with the management pack maybe?

    jueves, 14 de junio de 2018 10:28