Daily BSOD 0x00000109

Welcome
The reports give slight hints about hardware but drivers are, also, mentioned, No results are definitive. Lets test drivers and then move on to hardware if required.

Driver Verifier
I'd suggest that you first backup your data and then make sure you've got access to another computer so you can contact us if problems arise. Then make a System Restore point (so you can restore the system using the Vista/Windows 7 Startup Repair feature).

In Windows 7 you can make a Startup Repair disk by going to Start....All Programs...Maintenance...Create a System Repair Disc - with Windows Vista you'll have to use your installation disk or the "Repair your computer" option at the top of the Safe Mode menu .

Then, here's the procedure:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out. If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

If you can't get into Windows because it crashes too soon, try it in Safe Mode.
If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.
Driver Verifier - Enable and Disable

Since we did not run for 36 hours we may go back, but for now try this
Run for 8 passes.
Then test each stick in a good slot for 6 passes.
If you have dual channel, the results may be incorrect, if shows pass.
Guide to using Memtest86+ - Geeks to Go Forums

Allow me to show you what we are up against. I have highlighted that the verifier was enabled and the analysis, makes things difficult.
Im leaing toward hardware.

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
 
Loading Dump File [C:\Users\Richard\AppData\Local\Temp\Temp1_090212-minidumps.zip\090212-32042-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (3 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17835.amd64fre.win7sp1_gdr.120503-2030
Machine Name:
Kernel base = 0xfffff800`02c50000 PsLoadedModuleList = 0xfffff800`02e94670
Debug session time: Sun Sep  2 12:50:40.463 2012 (GMT-4)
System Uptime: 0 days 0:18:00.009
Loading Kernel Symbols
...............................................................
................................................................
...........................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 109, {a3a039d89e1f1541, b3b7465ef09be507, fffff80002ffffd0, 1}
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See Patching Policy for x64-Based Systems
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89e1f1541, Reserved
Arg2: b3b7465ef09be507, Reserved
Arg3: fffff80002ffffd0, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
 0 : A generic data region
 1 : Modification of a function or .pdata
 2 : A processor IDT
 3 : A processor GDT
 4 : Type 1 process list corruption
 5 : Type 2 process list corruption
 6 : Debug routine modification
 7 : Critical MSR modification
Debugging Details:
------------------
 
BUGCHECK_STR:  0x109
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP
PROCESS_NAME:  System
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80002ccf1c0
STACK_TEXT:  
fffff880`031855d8 00000000`00000000 : 00000000`00000109 a3a039d8`9e1f1541 b3b7465e`f09be507 fffff800`02ffffd0 : nt!KeBugCheckEx
 
STACK_COMMAND:  kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME:  Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP:  0
BUCKET_ID:  BAD_STACK
Followup: MachineOwner
---------

Without guidance from the reports and a pass for drivers. We have to go into hardware.
Go to the website of your hard drive manufacturer and test the drive.

If over clocking, restore default settings

martinix said:

You're saying the drivers passed the verifier?

The computer is not OCed and I checked the harddrive: no errors (I also used another hdd before and also faced the same issue).

By the way: I noticed that after an BSOD + reboot, the USB wifi stick is not recognised. Maybe that's helpful?

Did you run for 36hours?

Thats the way the Verifier works. If you get many BSODs try to leave on for 24 hours. Then submit all the BSOD reports. We will update all drivers that are caused by the verifier.