Also it said it failed to write a dump file with status: 0x000009C
I have no idea what any of the above means or wheather its related to NIS 2009 or not, all I know is everytime its happened, Norton has been running its Background full system scan.
I reported this problem awhile back but not much really came of it. But the problem came back today.
Heres what happens...
Somtimes when NIS 2009 is running its Full System Background Scan the BSOD will just suddenly appear, it only ever happens when Norton is running a background scan leading me to think its not actually a problem with my PC. After looking more into it, I've found a POSSIBLE link. When I checked in the Event Viewer and the History of the Defrag schedule, I noticed that each time the BSOD happened at the exact time of Norton scanning and Defrag running in the background.
Now I have no idea wheather or not the two running at the same time sometimes conflict, I can only give you the facts.
I've changed a Windows setting that will stop the system restarting next time the BSOD happens so I can tell you what it says.
In the meantime can this matter be tested at your end or something please tech? And anything else I can do/tell you?
Thanks
Ninko
P.S. I'm running NIS 2009 16.5.0.135, Windows Vista Home Premium SP1
Thanks for your feedback. As I said if/when the BSOD happens again I'll be able to post the message it gives. Other then that I'm not sure what else can be done. I'm hoping a Norton tech can look into this problem and shed some light on this.
Another reason I'm wondering if its a Norton and Defrag conflict is the fact that I have NIS 2009 (same version), running on a few other PC's and they've never had this problem once (touch wood), but they are all running Windows XP Home SP3, and as most know, defrag doesn't run on a schedule when running XP, and so less likely to 'meet' Norton's scan.
Ninko, does the same problem occur if you manually launch a full scan? Without knowing the text of the blue screen message I can’t be sure about your issue, but could it be the same as an ongoing SymEFA discussion? If you can reproduce the problem by manually launching a full scan, you may wish to try removing the SymEFA database per my instructions in the aforementioned discussion.
I have tryed starting a scan manually before and so far have never seen the problem trigger that way, but in saying that, the problem doesn't happen THAT often, especially not as often as some have described in the thread you gave me. I have tried running a manual scan and starting the Defrag background scan together aswell, but again it never triggers it, to date. I can try it again though if you like?
As for the problem described in the thread you gave me, I really don't see how it could be somekind of database corruption because I aint long reinstalled NIS 2009 using the Norton Removal Tool, and the exact same problem was still there.
Each time its happened I've looked for a dump file, but Windows never seems to create one.
Ninko, thanks for the additional information. You can try to defrag and manually scan if you like. Anything you can do to reproduce the crash sooner so that we can get the text on the blue screen would help. Until we have that text there’s not much that we can do.
Are you still experiencing this / have any luck reproducing this crash? We'd still like to look at the BSOD screenshot and / or dumps.
On a Vista system, you can check the Event Viewer for information on what happened, and the c:\windows\minidump directory for dumps, if you saw this crash.
Sadly I haven't been able to cause the crash myself, so I think its going to be a case of waiting for it to occur again on its own.
As for any logs, I've checked that location and no folder/file exists, and even in the Event Viewer its only logged the time and date that it experienced a 'unexpected shutdown'.
So at this present time I'm not sure what else I can do or tell you, but as I said eariler I've changed that Windows setting so it won't restart after a BSOD so I'll get the info you need.
Have you got the programmers maybe looking into the idea at their end, that I said I THINK might be causeing the problem?
We have been unable to reproduce the issue. For us to be able to research the issue, we'll need to get a dump file from the BSOD. If you're able to reproduce the issue and provide a crash dump, that would be most helpful in correcting this issue.
It would appear not as it failed to write the dump file with the status code above.
As I say, it doesn't always do it during the background scan, but everytime it does, the background scan was in progress. Read the thread I linked to, to read more if you haven't already.
I don't know what else to tell you. I'm assuming I'm the only one getting this problem then?
Your problem is probably different from the thread that you mention, although that thread doesn't have a stop code yet.
Stop code 0x00000077 can be caused by a number of issues ranging from a bad driver corrupting memory, to bad memory itself, a disk controller failure or a problematic hard disk. This also explains why you weren't able to get a dump.
Run "sfc /scannow" and "chkdsk". You may also want to try running a memory diagnostic tool.
Also it said it failed to write a dump file with status: 0x000009C
I have no idea what any of the above means or wheather its related to NIS 2009 or not, all I know is everytime its happened, Norton has been running its Background full system scan.
Strange how I've never had this problem before installing NIS 2009, stranger that background full system scan has always been running at the time of the crash, wouldn't you say?
A full system scan accesses your entire disk and a lot of memory. It’s one of the most stressful things that your computer can do. If there’s a minor problem lurking in the computer somewhere, it’s likely to show up there. You’ll also note that the very first item I listed as a possible culprit is a bad driver corrupting memory. Unfortunately, tracking down a bad driver can be very difficult and time consuming whereas running the checks that I suggested should fairly quickly and simply rule out or confirm the other, more probable, issues.
Message Edited by reese_anschultz on 05-12-2009 01:05 PM