cluberti

How about just search Technet for this stuff?

http://www.microsoft.com/windowsserver2008...icalInformationYou need Xeons running Intel's VT from this list (Select "Intel Virtualization Technology" from the "Supported Features" list and click the "Filter on Selections" button). I am not sure if it's a guarantee that everything on that list will work, but it's for sure anything not on that list isn't .

Well, it may or may not be nLite. All of your bugcheck codes are IRQL errors, meaning they aren't random (and as such your RAM is probably fine, and not the culprit). You've likely got a driver on there that's causing it - any chance to get a look at one of the .dmp files in the \WINDOWS directory?

That error code means "CLASS_NOT_REGISTERED", so a .dll file probably is not registered properly on your system. What exactly did you do when you nLite'd your installation source?

Unless it was a royalty OEM version (and I'm assuming it wasn't), keys are not architecture specific until they're activated (and even that can be changed later if you don't mind a call to the clearinghouse 800#). So, if you can find x64 media, your key will likely work just fine.

You could clean the print spooler (stop the spooler, search the registry for any mention of that .dll file, upgrade or remove any drivers that rely on it, or, if it's orphaned and no drivers use it, delete the .dll file and any reg references, restart the spooler).

The c000000f error code means the file on disk is missing or corrupt. You could probably replace it from the installation media after booting from a WinPE or recovery CD and see if that helps.

If you disable kapersky, does the problem occur? Also, when you do a full scan of your machine, does it come back as clean from kapersky?

Put it somewhere and let me know where I can grab it. Also, let me know the IP addresses of the netapp and the client(s). I'll try to get to it when I can.

How are you opening this page? Are you using Start > Run, or opening Internet Explorer and then typing in the URL manually in the address bar? Otherwise, this looks like overly agressive antivirus, as the problem it's reporting isn't a problem at all, it's LRPC it appears (perfectly normal between explorer.exe and iexplore.exe)...

Any old hardware will likely work fine - if you want to swing it, you could install Windows Home Server as well and make that second file server quite useful. If it's just a file server for you or just a few people, processor speeds matter little if performance isn't important, and if it runs Windows then RAM isn't really important either (although if you are planning on using Linux/SAMBA, note that SAMBA does cache things in RAM heavily and having too little RAM for the workload can really slow it down). As always, disk space is most important no matter what. If you want redundancy beyond OS-created arrays, however, you'll need to consider a discreet SATA RAID card.

Might be extremely interesting to get a network trace from the client accessing the share, one when accessing by IP, one when accessing by DNS. What's different? If they appear the same (other than huge delays in the \\IP access trace), then the problem is on the filer itself. Knowing that netapp filers sometimes have issues with ldap lookups, if your filer is configured to lookup AD or some other LDAP user structure, this could cause it too. One other thing, if you're accessing \\DNSNAME you may be using kerberos - \\IP forces NTLM, so you may have an NTLM issue on the network as well, perhaps your timeout is waiting for the netapp to timeout on a lookup? Gotta get those network traces (wireshark or netmon will work on a windows box).

I doubt you'll get a Windows 2000 disc. XP or 2003 scratched, maybe (since it's still available at retail), but a W2K CD is probably not an option unless you can get it through a premier / select agreement. If you or your company doesn't have one with Microsoft, you're better off finding one on ebay or trying to copy \i386 off the disc and creating your own. Another good reason to make copies and never use the original .

I can verify that this update was not included in SP3.

Let it autodetect (it will choose the correct ACPI/APIC and multiproc kernel). There's no need to do it automatically, XP setup will detect processors automatically. Are you using F5 for a specific reason?

Adding a 2K3 server to a 2000 domain does NOT require adprep. You only need to run adprep if you're adding the 2003 box as a domain controller, which you are not.

If you're in a 32bit process, and attempt to run an app, you will get the 32bit version of the app. There's no way around it without disabling redirection in code. Wait for the 6.5 version, as one of the stated features is using the 64bit binaries on an x64 system.

I'm sure there is, but yes, too much to ask here.

One other issue could be service pack extraction - it extracts the service pack to a temporary location (usually on C:, if that's the boot volume) and then runs update.exe from the temp location. You may have better luck extracting the service pack using the /x:<path to temp directory on D:> parameter, and then manually run update.exe from the extracted location. Also, I second tarun's suggestion - using SP3 is a better choice at this point than using SP2.

What I see is some sort of file corruption, perhaps? Appears to be a problem with the Vista source you downloaded (especially since you get the 80070241 during install/setup) - here's the errors from winerror.h: # 1 matches found for "-2147023504" ERROR_FILE_CORRUPT winerror.h # The file or directory is corrupted and unreadable. # 1 matches found for "0x80070241" ERROR_INVALID_IMAGE_HASH winerror.h # The hash for the image cannot be found in the system # catalogs. The image is likely corrupt or the victim of # tampering.

If you have the Scalable Network Pack (or W2K3 SP2) installed, and by chance have a broadcom NIC (or rebranded broadcom), you could be being bitten by the problem described in Microsoft KB 948496. It's the same types of issues you describe, so it's something to check.

To use an API like that, you need to be writing actual code. You can't call APIs from the shell directly.

nitroshift, i really don’t have any clue what else to change in the configuration i already set the page file size as per cluberti earlier post. There's probably not anything you can do to fix that, unfortunately, but we do know that we fail when using functions in win32k.sys, we've zeroed out a nonpaged pool region, and we crash when attempting to use that region. Since the memory manager itself doesn't zero out pool blocks (it only modifies the flink and blink on alloc/dealloc and coalescing), we know a driver did this. You could enable special pool and driver verifier, but that will increase pool usage in kernel (strongly suggest you uninstall any antivirus and non-Microsoft firewall software during this test to reduce the load on nonpaged pool during the test). You could also try to make sure all drivers (especially the nvidia driver for your video card) is up-to-date, and also make sure your Vista box is fully patched (including SP1), just to be safe.

Well, knowing C and C++ programming concepts (and having done it for awhile) is a definite help, since most of the code you analyze is in C/C++ (if you plan on debugging things in .net languages, for example, knowing the language and concepts will help there as well obviously). On top of that, understanding the structure of a process or the kernel in Windows and how the memory manager works are both quite important (Windows Internals 4th Edition). After that, debugging concepts and procedures can be picked up from a few places (including practice), but a good book is Advanced Windows Debugging.Also, the most important things to remember is that debugging takes practice, understanding of how what you are debugging works (otherwise, you won't recognize "not working"), and knowing that sometimes there's more art than science to debugging.

x64 versions of windows still run 32 bit apps, including viruses. I would still suggest the use of an antivirus application - not running all the time, mind you, but scanning your machine every few days, just in case.