I'm not at work so I don't have the reference handy, but there is a VMware
article for something like that.
Is the backup taken via a VM snapshot and the timings of the events match?
If so, it's a known issue, blamed on VSS, and can be ignored :-)
I've seen it in VMs with both NetBackup & CommVault as the backup software.
It's consistent on a VM that it happens to, but another VM built identical
in the same policy may not have those events.
Tony
On 31 Mar 2017 21:51, "Kurt Buff" <kurt.b...@gmail.com> wrote:
> Do those show up in the event log like this?
>
> Warning,2016-01-13 02:48:37,Microsoft-Windows-Ntfs,140,None,"The
> system failed to flush data to the transaction log. Corruption may
> occur in VolumeId: \\?\Volume{38f28236-b991-11e5-80ea-005056b43cf4},
> DeviceName: \Device\HarddiskVolume15.
>
> Information,2016-01-13
> 02:48:32,Microsoft-Windows-Ntfs,98,None,Volume
> \\?\Volume{38f28237-b991-11e5-80ea-005056b43cf4}
> (\Device\HarddiskVolume16) is healthy. No action is needed.
>
> Error,2016-01-13 02:48:37,Ntfs,137,(2),The default transaction
> resource manager on volume
> \\?\Volume{38f28236-b991-11e5-80ea-005056b43cf4} encountered a
> non-retryable error and could not start. The data contains the error
> code.
>
> Kurt
>
> On Fri, Mar 31, 2017 at 1:32 PM, Miller Bonnie L.
> <mille...@mukilteo.wednet.edu> wrote:
> > Windows Volume Shadow Copies?
> >
> > -Bonnie
> >
> > -----Original Message-----
> > From: listsad...@lists.myitforum.com [mailto:listsadmin@lists.
> myitforum.com] On Behalf Of Kurt Buff
> > Sent: Friday, March 31, 2017 1:19 PM
> > To: ntsysadm <NTSysADM@lists.myitforum.com>
> > Subject: [NTSysADM] WTF? Way too many Volume/Disk GUIDs
> >
> > I've got a 2012R2 file server with some problems. It recently locked up,
> and we had to force boot it through the VMware interface.
> >
> > It's got 13 drives with letters, plus the usual system reserved
> partition.
> >
> > Here are the volume GUIDs from PS:
> > # GWMI -namespace root\cimv2 -class win32_volume | select
> driveletter, deviceid | sort deviceid | ft -auto
> >
> > driveletter deviceid
> > ----------- --------
> > T: \\?\Volume{0b58699a-c6d4-11e5-80ef-005056b43cf4}\
> > J: \\?\Volume{27499b01-b5b4-43d7-98ae-17dbd948607e}\
> > G: \\?\Volume{3e50ec99-13b5-4d52-8091-2feeb695943f}\
> > \\?\Volume{3ec25e24-a333-11e3-80b4-806e6f6e6963}\
> > C: \\?\Volume{3ec25e25-a333-11e3-80b4-806e6f6e6963}\
> > D: \\?\Volume{3ec25e29-a333-11e3-80b4-806e6f6e6963}\
> > P: \\?\Volume{410169c9-33c3-11e6-80fb-005056b43cf4}\
> > X: \\?\Volume{515ebcdb-5c2e-11e4-80d4-005056b43cf4}\
> > K: \\?\Volume{79470a07-567a-11e4-80d3-005056b43cf4}\
> > I: \\?\Volume{88aa852a-1610-4875-8265-bb3c0612e5ef}\
> > W: \\?\Volume{a94520fe-16c6-11e6-80f7-005056b43cf4}\
> > S: \\?\Volume{cba78efd-34cd-11e6-80fb-005056b43cf4}\
> > U: \\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}\
> > M: \\?\Volume{d1ddfc3d-fa04-11e6-8109-005056b43cf4}\
> >
> > After the machine was back up and running, I started combing the system
> eventlog, and noticed something weird - there were a lot of volume GUIDs
> that didn't match my list above.
> >
> > I finally exported the system event log as a CSV file (it goes back as
> far as January of 2016), and cut and sorted the output, and found 2891
> unique volume GUIDs!
> >
> > That's just insane, and I have no explanation for this.
> >
> > Does anyone here have a clue to what this is about?
> >
> > Kurt
> >
> >
>
>
>
