This message was deleted.

could be write cache drive filling up. You're doing 'Ram with overflow to disk'?

There is no monitoring, so it stays an assumption but at boot there is 40GB free space at the overflow disk

and you can't get to the d$ drive when it's hung? are you persisting your eventlogs?

Logs are persisting indeed on D, have not tried administrative shares but services,eventvwr and powershell are not connecting

after you reboot the VM do the eventlogs indicate anything?

No, nothing. On the machine that is still going since this morning, the has not been overflowing to the vhdx

you have proper AV exclusions on the VDAs and on the PVS servers?

Yes

pvs servers event logs look ok?

Yep, nothing strange

just 1 image?

Tried multiple images

so it's happening to multiple separate images?

Yes, automation rolls out the images, so tried two complete different installations

are the new images, built from scratch?

Also yes

do the VDAs seem to freeze at the same time, or roughly the same time?

No, it is at random, some more times per day, and today 1 runs without problems

i've used folderchangesview to continue to export all c writes to an excel file on the d drive, that way you go back and take a look. Not 100% its an overflow issue, could also be maybe something scheduled or automatic windows updates kicking off, or vmtools geting upgraded or something like that

That was also what we thought. Due to the start after db issues, we are going to restore databases from backups. Will let you know tomorrow

you have offline support enabled? PVS DB issues shouldn't affect the VM performance after it's already up, but maybe the stream service is freaking out, would think that woudl show in eventlogs too tho

i agree that the clock still moving, but everything else unresponsive feels like an i/o pause (clock runs in memory). i/o pause for pvs...is either streaming disk is no longer streaming...or can't do writes (wc disk full). how long do they take to go from boot to unresponsive?

Seen the same thing twice before. Once was sccm discovering the box and trying to update filling wc. The other was a scan kicked off on all the vms, which killed io, but that was shown on pvs servers CPU usage being pegged

There was a good thread that included some WC filling troubleshooting info in it not too long ago. Let me see if I can find it.

It appeared to be Windows Defender who hung up the servers. Exclusions are in place..

good find, care to share how you came to the conclusion?

@Steve Noel , credits to my co-worker. He saw high disk latency, and first reaction is disable anti virus haha