Okay, well I started a thread yesterday asking about x64 on the 1420 because it wouldn't install for me...but it turns out NOTHING will install for me. I'm looking for guidance, because Dell simply won't help me on this issue.
As soon as I got my laptop, I tried installing x64. It installed perfectly fine, but on first boot it BSOD'd. I am a member of MSDN AA and receive x64 Business from there, I got Home Basic on my order because it was cheapest. So, I know this sounds strange...but here's my issues:
Anytime I install ANYTHING other than the Home Basic Disk that came with the system, my laptop will BSOD on boot. I tried both x64 AND x86 fresh installs from my disks WHICH I KNOW WORK. Before I even tried the x86 disk, I burnt ANOTHER x64 and same result. Yesterday, however, I noticed last night that now it'll boot from a cold start - but if you try to restart it or something, same problem happens.
It's very hard for me, because this is a brand new machine...that I can't use, except Home Basic. I'm *this* close to returning it to Dell, but their support won't help me because they don't support software you installed by yourself. Dumb.
The BSOD flashes for literally a quarter of a second, and I tried using my camera to make a video of it so I could slow mo it on my computer and see what it says, no luck. All I know is it says something about a STOP.
I KNOW other people have installed their own versions of Vista (including x64) on their 1420's, but why can't I?!? PLEASE HELP!
-
-
Have you tried taking out a stick of ram and seeing if that helps(i know you probably got x64 so that you can use 4gb but it could be a bad stick of ram)?
Also try to disable Automatic restart so that you can see the BSOD and record what it say by STOP
There should be an option in Advanced Boot Options menu(F8) or if you can access windows try these steps:
-
I know it's not the RAM, because I've taken out the factory RAM and put in my 4GB of GeIL from NewEgg and same result. I have since put the 2GB of Samsung RAM that came with my system back in. I'll follow those instructions now, since I think I can boot a special way.
-
A problem has been detected and Windows has been shut down to prevent damage to your computer.
Blah blah blah.
Technical Information:
** STOP: 0x0000007B (ox80606BA0, 0xC0000034, 0x00000000, 0x00000000) -
use a blue screen debugger
(in case you don't know how, but i think you would with your subscription, there is a guide i can email you, it won't fit in the attachments) -
I actually don't know how to run a blue screen debugger, but now that I know the error message I am doing some ideas. It says it's an inaccessable boot device, which makes NO sense at all...so there's some driver issues here, which is included in the Home Basic disk but not any of mine. But yes please send it to me anyway, I am PM'ing you my e-mail address.
-
hm the mailer daemon says its an invalid attachment
Default HOW TO: Debug Memory Dumps
When you get a stop error (Blue Screen of Death), your system writes a small file called a minidump. This is a small write up on how to debug memory dumps. This becomes extremely useful when you are trying to figure out what caused a particular stop error, and no filename was mentioned and/or it is undocumented.
You could always let Microsoft do it for you, but there is no gurantee they will answer, and it takes a very long time (over a month in my case).
Your first step is to download and install the Microsoft Debugging Tools found here: http://www.microsoft.com/whdc/devtoo...nstallx86.mspx
Once you have downloaded and installed these tools, go to start, all programs, Debugging Tools For Windows, Windbg. Once you open Windbg, you will presented with a blank screen. Click on File, Symbol File Path. Here you will enter the symbols path. Symbols are needed to effectively debug.
The path will be:
SRV*c:\symbols* http://msdl.microsoft.com/download/symbols
Enter in this path and click OK. Now, go to File, Save Workspace so that your symbols path is saved for future use. Now what you want to do is locate your memory dumps. They are usually located in %systemroot%/minidump (in my case C:/windows/minidump).
If you notice, they are usually named the date, and then a -*number* to indicate the order of minidumps that day. My example is called Mini061904-01.dmp (it happened today).
Inside of Windbg, go to File, Open Crash Dump and load the file. You will get a message to save base workspace information. Choose no.
Now you will get a debugging screen. Now it takes a little bit to run it, as the symbols have to be downloaded as they are needed. Then you will see information such as:
Symbol search path is: SRV*c:\symbols* http://msdl.microsoft.com/download/symbols
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini061904-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 XP Kernel Version 2600 (Service Pack 1) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp2.030422-1633
Kernel base = 0x804d4000 PsLoadedModuleList = 0x80543530
Debug session time: Sat Jun 19 19:06:57 2004
System Uptime: 0 days 1:03:36.951
Loading Kernel Symbols
....................................................................................................................................
Loading unloaded module list
..........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 86427532, {1db, 2, 3, b} <--This is your stop code
Unable to load image pavdrv51.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for pavdrv51.sys
*** ERROR: Module load completed but symbols could not be loaded for pavdrv51.sys
Probably caused by : pavdrv51.sys ( pavdrv51+7fc0 )
Followup: MachineOwner
---------
Now, we can already see what it was most likely caused by, in my case it was pavdrv51.sys, which is a Panda AV file.
If we want to get further in depth, we can use the command, !analyze -v at the kd> prompt to delve more info about the error:
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Unknown bugcheck code (86427532)
Unknown bugcheck description <--Its unknown, and not listed on the MS KB at all.
Arguments:
Arg1: 000001db
Arg2: 00000002
Arg3: 00000003
Arg4: 0000000b
Debugging Details:
------------------
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x86427532
LAST_CONTROL_TRANSFER: from f4198fc0 to 804f4103
STACK_TEXT:
f41f0964 f4198fc0 86427532 000001db 00000002 nt!KeBugCheckEx+0x19
WARNING: Stack unwind information not available. Following frames may be wrong.
f41f0ba0 f419920b 864db520 f419ccf0 00000000 pavdrv51+0x7fc0
f41f0c34 804ea221 865b8910 864a52c0 806ad190 pavdrv51+0x820b
f41f0c44 8055d0fe 864a5330 86305028 864a52c0 nt!IopfCallDriver+0x31
f41f0c58 8055de46 865b8910 864a52c0 86305028 nt!IopSynchronousServiceTail+0x5e
f41f0d00 80556cea 000000a4 00000000 00000000 nt!IopXxxControlFile+0x5c2
f41f0d34 8052d571 000000a4 00000000 00000000 nt!NtDeviceIoControlFile+0x28
f41f0d34 7ffe0304 000000a4 00000000 00000000 nt!KiSystemService+0xc4
00cdff70 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
FOLLOWUP_IP:
pavdrv51+7fc0
f4198fc0 ?? ???
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: pavdrv51+7fc0
MODULE_NAME: pavdrv51
IMAGE_NAME: pavdrv51.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3e8c072b
STACK_COMMAND: kb
BUCKET_ID: 0x86427532_pavdrv51+7fc0
Followup: MachineOwner
---------
Update: After the intial run of the debug process, you can use the command !analyze -v to gather more information.
Now that may be more infor than you need. This tutorial only covers minidumps, however, if needed, you could change your memory dump options to do a complete dump. This is useful, however, very cumbersome, as the file generated will be the same size as your amount of ram.
Note: Make absolutely sure that your symbol path is correct. If it isn't, then you will get symbol errors and not likely be able to debug the dump to get the info you desire.
Screenshots to follow. I hope this info is useful, I find it invaluable to finding out what is causing random, sporadic, and/or obscure stop errors.
_____________________________________________________-
credit to: majorgeeks.com, Adrynalyne ,member of majorgeeks -
Okay, well I *think* I found a fix...but to be honest I don't know the difference.
In the BIOS I changed the SATA mode from ACHI to ATA and now it works fine (and I even think my system might be a tiny bit faster). What's the difference, and does it hurt anything for me to keep it on ATA? -
hehe you just told your sata controller to emulate IDE
i don't know the pros/cons. -
Well I of course know SATA is faster than IDE, but I don't exactly know what AHCI is. I also know that I'd rather emulate IDE than have a non-booting system...anyone else?
1420 won't let me install ANYTHING!
Discussion in 'Dell' started by DoubleBlack, Jul 23, 2007.