cluberti

That's pretty odd, although I'm not seeing the problems on any of my machines here (not a scientific test, I know, but I've been unable to repro this). What happens if you run IE in safe mode (iexplore.exe -extoff) when running Windows in Safe Mode with Networking?

You may want to read this before going any further.

If you can, I would suggest trying another nlite run without the timezone hotfix to see if the same errors occur.

Moving to more appropriate forum.

Until they support the .vhd format, I probably won't use it. It's nice and fast, but I can't run my current VM images in it without imaging them first or reinstalling completely, and that wasted time offsets the benefits of the additional speed for me. Nice product though .

Correct - however, we are doing work in win32k.sys when the crashes occur (win32k!SURFACE::bDeleteSurface+0x228), which would indicate a video card driver issue. What video card is in that machine, and what driver set are you running for that card? First, you need a PS/2 keyboard attached for this to work (and you also need to reboot for the reg change to work). Second, since the machine is crashing on it's own, there's no need to do a keyboard dump - it'll crash dump on it's own every time it BSOD's. If you set the registry key for CrashDumpEnabled to 1 and reboot, the option for a complete memory dump will NOT be seen in the GUI - however, it'll still do a complete crash dump because the CrashDumpEnabled value is 1. If you go into the GUI and click OK, it'll reset that to whatever was in the box - so, set CrashDumpEnabled to 1, make sure the page file on your C: drive is RAM+50MB or so, and reboot. Don't go back and check anything, just leave it as-is . The next time you get a memory dump from a BSOD, it'll be a complete dump.

Not quite sure how it would affect you, although the question is did you modify the installation media at all? Those errors aren't fatal, but they could result in unpredictable behavior later when trying to install SP3, for instance.

I think you're short two prisoners, although if done right only 8 of them will die in a worst-case scenario .

Sorry, I haven't had the chance to take a look at the file yet. I'll see if I can get to it tomorrow or Monday .

That's highly subjective, and depends on what you do on your desktop. If you need to prioritize background tasks, need to host more than 10 simultaneous incoming network connections, or run full IIS, then 2003 would be better. If you are running a gaming rig, XP or Vista will likely be just as good - and cheaper to run too, as an OEM XP license is USD $99, whereas a Server 2003 Standard edition OEM license runs at least USD $400 to start. The current version of Server 2003 is 5.2.3790.3959, which is the SP2 build number, and yes it is the latest.

Very cool

First off, neither of those messages are speaking to the RAM in your machine, they're talking about VIRTUAL memory (kernel mode address space, to be exact) and the IRQL of a driver. This is almost always caused by a bad driver, so getting a dump of the problem for us to analyze would help out a lot.

That's the one - looks like a driver called tp4track.sys is the culprit. Since this is a minidump a lot of info is missing that would be in a full dump (like the handle table), but I'd say it's pretty obvious that this driver is causing the problem - note line 04, where the first parameter passed to tp4track.sys at offset 0x1c9a is "00000000", that will cause a bugcheck if this is a KMDF driver (which it is): kd> kvn # ChildEBP RetAddr Args to Child 00 f41e0a44 f8116c3b 0000010d 00000004 f810dc80 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo]) WARNING: Stack unwind information not available. Following frames may be wrong. 01 f41e0a60 f8117480 821bc770 00000004 f810dc80 Wdf01000+0x28c3b 02 f41e0a80 f810dc80 821bc770 81f7b1c8 00000000 Wdf01000+0x29480 03 f41e0a98 f8727c9a f872a000 82093ec8 81f7b1c8 Wdf01000+0x1fc80 04 f41e0ad4 f872b204 00000000 820c7728 00000013 tp4track+0x1c9a 05 f41e0b78 f812abde 7de9bd70 7e60c228 000000c8 tp4track+0x5204 06 f41e0b9c f812bd89 7de9bd70 7e60c228 000000c8 Wdf01000+0x3cbde 07 f41e0bcc f812d929 7e60c228 819f3dd0 82164288 Wdf01000+0x3dd89 08 f41e0be8 f812ebe0 82164200 f81539b8 82371290 Wdf01000+0x3f929 09 f41e0c04 f8130bb1 00000000 81dc6fb8 821d0818 Wdf01000+0x40be0 0a f41e0c28 f8120272 82093ec8 f41e0c58 804e37f7 Wdf01000+0x42bb1 0b f41e0c34 804e37f7 8209cf00 82093ec8 806ed070 Wdf01000+0x32272 0c f41e0c44 8056a148 82093f38 81b10e38 82093ec8 nt!IopfCallDriver+0x31 (FPO: [0,0,0]) 0d f41e0c58 8057ad03 8209cf00 82093ec8 81b10e38 nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo]) 0e f41e0d00 8057d281 00000058 00000000 00000000 nt!IopXxxControlFile+0x611 (FPO: [Non-Fpo]) 0f f41e0d34 804de7ec 00000058 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) 10 f41e0d34 7c90eb94 00000058 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f41e0d64) 11 0006f9ec 00000000 00000000 00000000 00000000 0x7c90eb94 kd> lmvm tp4track start end module name f8726000 f8730000 tp4track T (no symbols) Loaded symbol image file: tp4track.sys Image path: tp4track.sys Image name: tp4track.sys Timestamp: Thu Apr 26 08:12:22 2007 (46309726) CheckSum: 0000CBF2 ImageSize: 0000A000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

It's crashing because a debug breakpoint in the code occurred, which means likely there's a bug in the code for the application. You could download and install Microsoft's Application Verifier, and in the App Verifier application create a "basics" rule (the default) for the MeGUI .exe file and then run the app with adplus attached in crash mode, but again, the breakpoint means that likely there's bad .net code in that application.

Yes, this is a documented issue and a fix is in the works. Nothing more I know about it than that, although if you multiply the results of the initial calculation by 2, you'll get the desired number, so the calculation itself is fine, but the display logic is flawed.

IRQ sharing of IRQ's that high is usually fine, although seeing your video card and the USB controller on 16 is probably why the USB isn't working. I'd say you may have some BIOS settings causing this, and going in and choosing a reset to the defaults (if that option exists) is probably a good start, although you may need to reinstall.

Somewhat, yes: Bug Check 0x10D: WDF_VIOLATION The WDF_VIOLATION bug check has a value of 0x0000010D. This indicates that Kernel-Mode Driver Framework (KMDF) detected that Windows found an error in a framework-based driver. - The first parameter passed (00000004) after the bugcheck code means "A NULL parameter was passed to a function that required a non-NULL value" - The second parameter passed (f812fc80) isn't helpful without a dump file, as the first parameter being 4 means this points to the function in memory that had the third parameter (00000000, or NULL) and is the offender. Did your system generate any *.dmp files on the disk at all when this occurred?

I guess I fail to understand what it is you're trying to do - you state that you are unable to pass WGA, and also that you need to automate entries into the registry. If you need to automate reg entries, simply create a .reg file with the entries and run regedit /s <regfilename>.reg in your first run script. I'm not sure exactly how that affects WGA though - perhaps you could be more specific.

If you create a file as administrator, and then assign that user as the owner (and the user "CREATOR OWNER" has the rights to do so), the user can delete that file if necessary.

Well, a few, but a memory dump of it happening would be great. If you could configure your machine to gather one, and then compress it and make it available once the problem next occurs and you actually have a .dmp file, that'd be great.

No, Vista will not act as a DFS root. Read my comment again :

Why does your installation not pass WGA validation is the real question...

Unfortunately, to completely bypass this limitation you should be running x86 Vista, or get a signed driver for the device (or a new device). I know none are easy "fixes", but technically x64 is much more demanding about driver structure, so using unsigned drivers at least presents a greater possibility that the driver will cause an unstable system.

Well, you could do the binary math and figure it out, or you could search for an online subnet mask calculator which can do most or all of it for you.

DFS will allow you to create a namespace (either domain or local to the file server) to place your current shares under - DFS is mainly to allow multiple shares from multiple servers to appear as a single logical namespace under the DFS root. For example, a domain DFS root (say domain.com) may have the following structure once created and configured: \\domain.com\DFSshare | |---\Videos | | | |---\MediaComputer (is actually \\MediaComputer\Video) | | | |---\DenHTPC (is actually \\DenHTPC\Video) |---\Music | |---\MediaComputer (is actually \\MediaComputer\Music) | |---\FileServer (is actually \\FileServer\Music) That way, you can map one drive to \\domain.com\DFSshare, and access all of the other folders in the tree below it without having to map any additional drives. This allows you to disperse data amongst multiple servers, but have all of it appear as one logical share structure. You do need to use a Windows Server 2003 box for this, unless you want to setup a Linux box and try and get Samba working as a DFS root (it's painful, but can be done).