If you are in a critical situation where a production system is in dire need of repair, you may be better off having it serviced at a local shop or even go so far as to backup the data to another system and use that for the time being. Without access to
the faulting system, the amount of data we have and the resources to try and remedy this are finite. It may be free, but that comes at a cost of time and accuracy of solution. If you still wish to pursue this avenue, then read on.
More data is necessary to work with beyond what is already presented, so it'll be good to answer a few questions. Is the crash consistently showing that the bugcheck is D1? Are the 2nd and 3rd parameters also consistently 2 and 8, respectively? How frequent
are the crashes? Is there any action or activity on the system that will invoke the symptoms?
At least one minidump will be needed for this, but first it's best to turn on Driver Verifier in order to potentially increase the accuracy of the minidumps. In the Start Menu type
verifier and it should show up
verifier.exe. When that is open, click
Create custom settings then proceed. Go to
Select individual settings from a full list and proceed. In the list, select everything
except Low resource simulation, IRP logging and
Force pending I/O requests, then proceed. Check
Select driver names from a list. Select all drivers that do
not have Microsoft Corporation as the Provider. Finish setup, then restart the system.
This may cause a boot loop, in which case if so then Driver Verifier is doing its job. Once your system has crashed a couple of times, go into Safe Mode (tap F8 key during system startup), then open Driver Verifier again, except at the main menu select
Delete existing settings and click Finish, then restart again. You should now be able to enter Windows normally. Collect the minidumps present in
\Windows\Minidump directory, archive em via zip, rar or some other method, and attach it to your original post.
In the meantime, while everyone is looking at your dump files, you can also take this time to do hardware tests. Start with 7+ passes of
Memtest86+, then do an overnight run of
Prime95 on Torture Test on Large FFTs setting. Make sure that your system's cooling - especially CPU - is sufficient, as this will stress the CPU to its maximum for a good length of time. You may use something like
HwInfo to monitor temperatures (click 'Sensors only' at startup). Report back on results from both Memtest and Prime95.
As for the System integrity check problem, make sure that you run such repairs from a Windows recovery or installation disk. You can access it by click
Repair my computer when it starts up. Aside from the usual tools, you may also want to enter Command Prompt and type
CHKDSK /R and after that is complete follow up with
SFC /SCANNOW. You may also need to type in the letter of your system drive (typically C:) for CHKDSK in case it does not start. If any reports issues, you will want to do a restart of the system
and run them a second time.
As of right now, all I can garner from the bugcheck info you provided is that it crashed because some code erroneously attempted to call itself, or the instruction pointer failed to update itself. What code made the mistake, I cannot tell without at least a
minidump to go on. It does seem more like a software issue than hardware, though again, I'm not sure without more data.
I hope that all is enough to work on for the time being.
