This content has been marked as final. Show 3 replies
Whatever you think or whatever you see happening, regular software cannot cause a BSOD. It can certainly trigger one because the use of an API call might lead to the usage of a faulty driver for example (which operate in a 'ring' that can actually cause the kernel to halt execution). But whatever problem you are having it is not rooted in either installers, it is in your system setup specifically.
So a warning to you: be on the lookout for similar failures and perhaps see if you can update for example your motherboard drivers.
Thanks for the comment. It prompted me to describe the BSOD in more detail.
Out of the 11 times I experienced these BSOD's while downloading 7u2, I got several different bug check strings:
MEMORY_MANAGEMENT 4 times, Points to ntkrnlpa.exe
IRQL_NOT_LESS_OR_EQUAL 3 times, Points to fltmgr.sys, MpFilter.sys, ntkrnlpa.exe (once)
Points to halmacpi.dll, ntkrnlpa.exe (twice)
BAD_POOL_HEADER Twice, Points to fltmgr.sys, halmacpi.dll, ntkrnlpa.exe
KERNEL_MODE_EXCEPTION_NOT_HANDLED Once, Points to ntkrnlpa.exe
PFN_LIST_CORRUPT Once, Points to ntkrnlpa.exe
Interesting, isn't it? It seems Windows is not quite sure what to blame the blue screen for. While I am quite aware of app developers' tendency to blame device drivers, driver coders blaming BIOS, BIOS coders pointing to hardware for the "cause" of a problem, I am not interested in semantics on the difference between causing and triggering. It is certainly true that many BSOD has their roots in device driver and BIOS bugs, but I am not so sure if this is the case here. As I don't have the time to look into the way Adobe lets its updater to make downloaded file status to survive a reboot, how Oracle installer performs CRC and other operations, and how Windows system files and config protection schemes interact with them, I chose to be a news reporter.
While I am quite aware of app developers' tendency to blame device driversIt is because this is the only thing that makes sense. As an 'app developer' you don't mess with device drivers or hardware, you only mess with operating system provided services which are themselves linked to layers of abstraction, validations and failure handling. You don't 'play a sound through the soundcard' for example, you play a sound through 'a sound API'. You don't use the videocard to render graphics, you use Direct3D or OpenGL which themselves are abstractions on top of the videodrivers. You don't access memory location 0xBAADF00D directly, you ask a block of memory from the operating system and you use that. You don't write bytes to a specific cluster on the harddrive, you write to a 'file'. Etc. etc.
Good times we live in, the OS keeps us developers safe and secure from the evil computer and the users safe and secure from the malfunctions that we cannot avoid to produce. now if only them pesky OS, device driver and system service developers would get their act together.