bharatgade wrote:
That scenario is kind of hard to reproduce it. but still i got successful to fetch complete memory dump out of that machine in that scenario then i analyzed full memory dump using microsoft WinDbg tool. WinDbg tool displayed faulty driver module name and call stack as below
…
Module Name: MMTEProxy (Installed Driver)
NMI_HARDWARE_FAILURE (80)…
Arguments:
Arg1: 00000000004f4454
VMWare raises NMI to signal certain fatal error conditions. Note that
Arg1 contains the ASCII string “ODT” (or “TDO”). I could not find any
Google results in a quick search (“vmware nmi odt”), but I’ll wager this
is some kind of watchdog timeout. Have you done any analysis to
determine exactly how long you might wait for those spin locks? I’m
sure you haven’t, but that’s where you’d want to look.
And I also checked that there is no any deadlock condition or curretnly held lock by any thread. still i am not getting what causing this issue. whether its lock is not handled properly at code level or some particular situation.
Well, that statement is patently false, right? The code you posted
shows that you hold both the session table lock and the process table lock.