Server 2012 VM Guest (AppassureCore) keeps getting BugChecks...not sure whereto start?

Question

Bear with me here as there is a lot of technical data I need to present I believe so that I can help you all help me :)
I have a Server 2012 VM Guest running on Hyper-V on a Server 2012 host.
The VM is running my main Appassure core - I have a replicated core also but am having no issues with it at all.
The Host machine has 2 XEON E5540s, for a total of 8 cores. It has 48 GB of memory.
There is also another VM guest running on this host and that is a Server 2008 R2 that is my FSMO master and has no issues whatsoever.
Both guests are running Virtual Memory with starting memory of 512 and max of 49152.
Both VMs and the host each have their own GBe dedicated NIC.
The problem 2012 VM is setup with 4 virtual processors. The Server 2008 R2 (non-problem) VM is running on 8 Virtual processors.
Since the 2012 machine is running Appassure, I have an iSCSI connection to a NAS device. This is the same setup as the replicated Appassure core in every way except that the replicated core is a physical machine.
All integration services are installed and available.
For the most part, just before each bugcheck, I get a rapid succession of around 350 errors that happen within 2 minutes, then the crash...
I won't list them all, but here are the main ones:
EVENT 12293, VSS (I get 4 of these in a row.)
Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}. Routine details IVssSnapshotProvider::QueryVolumesSupportedForSnapshots(ProviderId,8388617,...) [hr = 0x8000ffff, Catastrophic failure
Operation:
   Query volumes supported by this provider
Context:
   Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
   Snapshot Context: 8388617
Event 20, iScsiPrt
Connection to the target was lost. The initiator will attempt to retry the connection.
Event 7, iScsiPrt (2 of these)
The initiator could not send an iSCSI PDU. Error status is given in the dump data
Then another 12293, VSS error
EVENT 481, ESE
AppRecovery.ExchangeCheckHost (3840) DSM_JET_INSTANCE: An attempt to read from the file "C:\ProgramData\AppRecovery\MountPoints\064ab6b0-e8e9-4862-9756-e47f19ca248f\E__\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb" at
offset 7934615552 (0x00000001d8f0a000) for 8192 (0x00002000) bytes failed after 30 seconds with system error 121 (0x00000079): "The semaphore timeout period has expired. ".  The read operation will fail with error -1022 (0xfffffc02).  If
this error persists then the file may be damaged and may need to be restored from a previous backup.
Event 419, ESE
AppRecovery.ExchangeCheckHost (3840) DSM_JET_INSTANCE: Unable to read page 968580 of database C:\ProgramData\AppRecovery\MountPoints\064ab6b0-e8e9-4862-9756-e47f19ca248f\E__\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb. Error -1022.
EVENT 454, ESE
AppRecovery.ExchangeCheckHost (3840) DSM_JET_INSTANCE: Database recovery/restore failed with unexpected error -1022.
I then get about 6 more of the VSS errors 12293
Then comes the motherload - a flood of Ntfs errors. Here are some examples:
EVENT 55, Ntfs
A corruption was discovered in the file system structure on volume C:\ProgramData\AppRecovery\MountPoints\064ab6b0-e8e9-4862-9756-e47f19ca248f\E__.
The Master File Table (MFT) contains a corrupted file record.  The file reference number is 0x800000000050e.  The name of the file is "<unable to determine file name>".
EVENT 131, Ntfs
The file system structure on volume C:\ProgramData\AppRecovery\MountPoints\064ab6b0-e8e9-4862-9756-e47f19ca248f\E__ cannot be corrected.
Please run the chkdsk utility on the volume C:\ProgramData\AppRecovery\MountPoints\064ab6b0-e8e9-4862-9756-e47f19ca248f\E__.
I then get about 300 more of the EVENT 55, Ntfs errors that are all exactly the same except that they reference a different 'File Reference Number'
Then the bugcheck happens. 
Now, I ran WinDBG and it pretty much gave me an answer that didn't really help all that much:
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: fffffa8305c6e040, Object whose reference count is being lowered
Arg3: 0000000000000010, Reserved
Arg4: fffffa8301d642a1, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.
Debugging Details:
Page 198c7b not present in the dump file. Type ".hh dbgerr004" for details
DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
BUGCHECK_STR:  0x18
PROCESS_NAME:  Core.Service.e
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from fffff80160a0c5ae to fffff80160868440
STACK_TEXT: 
fffff880`05822418 fffff801`60a0c5ae : 00000000`00000018 00000000`00000000 fffffa83`05c6e040 00000000`00000010 : nt!KeBugCheckEx
fffff880`05822420 fffff801`608c4841 : fffffa83`01b92940 00000000`00000001 fffff880`05822800 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x4bfe4
fffff880`058224c0 fffff801`608ad4d1 : fffffa83`0209ab68 fffffa83`01b92940 fffffa83`00000011 fffff801`00010224 : nt!ExpWaitForResource+0xa1
fffff880`05822550 fffff880`01960447 : 00000000`00000002 00000000`00000000 fffffa83`02099180 fffffa83`075ab010 : nt!ExAcquireResourceExclusiveLite+0x1e1
fffff880`058225c0 fffff880`01960809 : fffffa83`075ab010 fffffa83`02099180 ffff8975`f1909000 00000000`00000000 : Ntfs!NtfsVerifyCorruption+0x9b
fffff880`05822670 fffff880`0183b0b4 : fffffa83`075ab010 00000000`00000000 fffffa83`02513010 00000000`00000001 : Ntfs!NtfsProcessAttachedCorruptions+0x85
fffff880`058226e0 fffff880`0183b1c6 : fffffa83`00240000 fffffa83`075ab010 00000000`00000000 fffffa83`02513010 : Ntfs!NtfsCleanupIrpContext+0x574
fffff880`05822730 fffff880`018c07aa : 00000000`00000000 fffffa83`008c7f20 00000000`c0000022 00000000`00000000 : Ntfs!NtfsExtendedCompleteRequestInternal+0xd6
fffff880`05822770 fffff880`019276fb : fffffa83`075ab010 fffff8a0`01ff0e00 00000000`00000000 00000000`00000000 : Ntfs!NtfsLockVolume+0x2e9
fffff880`05822830 fffff880`01926f06 : fffffa83`02513010 00000000`00000000 00000000`00000000 00000000`00000000 : Ntfs!NtfsUserFsRequest+0x547
fffff880`05822870 fffff880`00a83845 : fffffa83`04abb5c0 fffff801`60c40cc5 fffffa83`025131b8 fffffa83`02513010 : Ntfs!NtfsFsdFileSystemControl+0x126
fffff880`05822970 fffff801`60c3d6c7 : fffffa83`025131b8 fffffa83`02513010 fffff880`05822cc0 fffff880`02c62180 : fltmgr!FltpFsControl+0x165
fffff880`058229d0 fffff801`60c58fa6 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x7e5
fffff880`05822b60 fffff801`60867453 : 00000000`4273b7f8 00000000`4273b1e0 00000000`0807c568 00000001`80994dc8 : nt!NtFsControlFile+0x56
fffff880`05822bd0 000007fa`02ad2f7a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`4273b198 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fa`02ad2f7a
STACK_COMMAND:  kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+4bfe4
fffff801`60a0c5ae cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+4bfe4
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
IMAGE_NAME:  ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  5165e551
BUCKET_ID_FUNC_OFFSET:  4bfe4
FAILURE_BUCKET_ID:  0x18_nt!_??_::FNODOBFM::_string_
BUCKET_ID:  0x18_nt!_??_::FNODOBFM::_string_
Followup: MachineOwner
If you have made it this far, I thank you. I really have no idea where to go with this and am worried because obviously it involves my main backup so any help would be greatly appreciated.
It should be said that I am also creating a backup of this actual machine from within the machine itself, using AppAssure. Not sure why that matters much except that I am guessing the VSS errors are referring to the actual machine itself - not a protected external
machine. 
Thanks again!
Mike

Answer 1

I have done a chkdsk on our core and it still pulled this error today. It gives the 474 error:
Description: AppRecovery.ExchangeCheckHost (5648) DSM_JET_INSTANCE: The database page read from the file "C:\ProgramData\AppRecovery\MountPoints\6b27d60b-b8b3-4f79-9a4c-82ef68e71cba\H__\Microsoft\Exchange\IDP-EX01-JRNL1\IDP-EX01-JRNL1.edb" at offset 63335301120
(0x0000000ebf140000) (database page 1932839 (0x1D7E27)) for 32768 (0x00008000) bytes failed verification due to a page checksum mismatch.  The expected checksum was [714d714d506b3ced:6b1894e799aebc30:ed5612a95c689a54:cbbd3442bc4760a4] and the actual checksum
was [8fad7052506b3ced:6b1894e799ac3638:ed5612a95c6a105c:cbbd3442bc45eaac].  The read operation will fail with error -1018 (0xfffffc06).  If this condition persists then please restore the database from a previous backup.  This problem is likely
due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.