cluberti

If it's set to auto manage, it should shrink it on reboot back to a smaller size based on the amount of RAM in the machine and usage patterns. Again, unless you think you need it, configuring a min and max size manually to between 600 - 800MB on Vista x86 should be fine.

Well, I always recommend a paging file, but the size depends on what you need. I always recommend it because there are some memory operations in kernel that really do require that you have a pagefile as a backing store in case some of the executive and paged pool needs to be paged out. However, if you don't plan on gathering data from a crash if it was to occur, I recommend a pagefile that is ~600MB in size for an x86 system with 4GB of RAM - that's large enough to handle the entirety of kernel paged pool being paged out, but still modifies your commit limit in such a way that almost all pages will be in RAM at any time. However, everyone's system usage is different, so monitoring your machine with perfmon (specifically the Process > Working Set counter for the _Total instance) to see how much VA across all running processes is actually in RAM. If you notice that the _Total counter gets up near 4GB, you need a pagefile, because you have the very real possibility your system will try to commit more VA to RAM than you have RAM to back it. When that happens, you'll likely get very odd behavior in the app, probably some app crashes, and the kernel won't like it too much either and Windows will possibly become somewhat unstable for a time as well. If you find that your _Total instance for the Working Set counter in Process stays under 3.5GB, you should be just fine with a 600MB or so pagefile.

Can you write your batch as a vbscript instead? If you can, and it requires no input, you can run it with cscript and it will always run in the background and never steal focus (unless it needs user input, which I'm guessing your batch does not).

The built-in IME packs (like in XP) modify the ability to view and enter text INSIDE of applications. You only need the actual Language MUI packs if you want to change the text in the OS or applications themselves.

Yes, a "page" is 4K, so all "pages" in memory written to the paging file are thus 4K in size, always. I wouldn't say it would have no effect, but it would be so minimal as to not even bother with the hassle and worry of losing a paging file if one of the 2 disks goes bad. If you're going to do RAID, a RAID1 would be much better for the paging file. Yes, that might speed things up a bit as your probability of hitting a location in the page file that would split the I/O would be greater. I'm not sure I'd recommend it, but the theory is sound. That's because you've changed your commit limit, and forced the NT memory manager to be biased towards committing to RAM so that it will only be able to commit VA pages from applications into RAM. The memory manager can only commit pages to a backing store (RAM or paging file), and if you only have RAM (or RAM and a very small paging file), all or most of your pages committed will have to be in RAM because they can be nowhere else. It'd be a problem if you tried to commit more VA than you have RAM in the box, but that's the only drawback to not having a paging file performance-wise. You can't dump the box or get data from a crash without a paging file, but that has nothing to do with performance.

You can try going into the device manager and going into the properties of the computer object and changing the driver to standard PC, and then once you reboot and test that it is working you can reboot again and disable ACPI in the BIOS if you are able.

Yes - if performance is your only concern, having the paging file on a separate volume (even if it's 7200RPM vs 10K) will provide better performance to the paging file than if it was on the OS disk. You have to remember that a page in memory is 4K in size - so the pagefile writes memory pages to disk, meaning all of it's "files" inside pagefile.sys are 4K in size. The problem with RAID0 and pagefile.sys is that the writes will be to a section of the paging file which could be anywhere on that RAID0 volume - you don't get any speed benefit unless you happen to write to a section of pagefile.sys that is spread across both drives, otherwise you just write to the one disk that has the section of pagefile.sys your page is going to. You'll see benefit if you page a lot, but if you have a decent amount of RAM you probably won't see any benefits of a RAID0 vs a RAID1 for pagefile.sys. This is one of the files that really doesn't benefit from fast RAID configurations like RAID0, 0+1, or 10, but will suffer in a tolerant array type like RAID5 (reads are fast, writes are slower). That is why it is usually recommended to store the OS and pagefile.sys on RAID1 arrays - if you must use a RAID, using a RAID1 provides some fault tolerance without the write penalty, and isn't as expensive in disk space as a RAID10 or 0+1 - and you won't lose it entirely if you lose one of the disks in the array like you would if you use a RAID0.

Try submitting a request for the hotfix here.

Even I have to admit that's a funny screenie

Since that card was first designed for Windows 95, you'll probably have better luck if you disable ACPI in the BIOS and then install XP using the Standard PC type (press F5 when you are prompted to press F6 for any additional drivers, and select the "Standard PC" option). IIRC, this is what a friend of mine had to do to get his working properly - although it still didn't work 100% the way he expected, and upgraded to a Creative SB Live for $15 USD or something like that (it was really cheap, and worked much better) .

You can have at most 4 primary partitions on one physical disk, and there's no way around this. That's why extended partitions exist - you make one primary partition (the boot partition), and one extended partition taking up the rest of the drive. You should be able to create as many logical partitions inside that one extended partition as you desire.

No problem - hopefully you can figure it out and post back what you ultimately decided to do .

not only that, but eventually your program has to run - and anyone can debug it and disassemble / reverse engineer it in a debugger. There's not much you can do about that either.

This is an XP question - moving to the right location.

No, they still use keys. It's just the activation methods that have changed (like MAK and KMS for volume license customers).

Once those vendors release packages built on MSI 4.0, that should be a thing of the past. It'll take some time, though.

KB is 918837 Product is Windows XP Platform is x86 Language is probably English from your flag Email address is your email address you want Microsoft to send the link to download the file to

OK, since the symbols for ntoskrnl.exe from 931784 aren't anywhere I can find (that's the version of the kernel you have on your box, which is the latest available), I'll have to do this manually in assembly without stacks - sorry, this won't be as easily readable as some of my other debugs here: // This is the stack where the problem occurred: 0: kd> dds 80556218 805562a8 80556218 8053753a nt+0x6053a // The bugcheck 8055621c 000000c2 80556220 00000007 80556224 00000cd4 80556228 020a0003 8055622c 86ef8498 80556230 00000000 80556234 80556284 nt+0x7f284 // Driver verifier 80556238 80550fc5 nt+0x79fc5 // The pool free call 8055623c 000000c2 80556240 00000007 80556244 00000cd4 80556248 020a0003 8055624c 86ef8498 80556250 86ef8498 80556254 87145f50 80556258 00000000 8055625c 870a37b0 80556260 870a3788 80556264 00000000 80556268 86ef84e0 8055626c 00000000 80556270 f7586ed0 NDIS!NdisAcquireSpinLock+0x11 80556274 f7586eee NDIS!NdisReleaseSpinLock+0x11 // The call into ndis from the driver 80556278 80556290 nt+0x7f290 8055627c 00000000 80556280 00000001 80556284 80556294 nt+0x7f294 80556288 805503e3 nt+0x793e3 8055628c 86ef8498 80556290 00000000 80556294 805562d4 nt+0x7f2d4 80556298 f7c4d135 NetMotCM+0x2135 // The driver that likely is the problem 8055629c 86ef8498 805562a0 86ffc9b7 805562a4 86ffc8d8 805562a8 804e18ff nt+0xa8ff // This looks like the pool free call on edi: 0: kd> u 80556238 nt+0x7f238: 80556238 c50f lds ecx,fword ptr [edi] 8055623a 55 push ebp 8055623b 80c200 add dl,0 8055623e 0000 add byte ptr [eax],al 80556240 07 pop es 80556241 0000 add byte ptr [eax],al 80556243 00d4 add ah,dl 80556245 0c00 or al,0 // This looks like driver verifier checking the call: 0: kd> u 80556234 nt+0x7f234: 80556234 846255 test byte ptr [edx+55h],ah 80556237 80c50f add ch,0Fh 8055623a 55 push ebp 8055623b 80c200 add dl,0 8055623e 0000 add byte ptr [eax],al 80556240 07 pop es 80556241 0000 add byte ptr [eax],al 80556243 00d4 add ah,dl // This is the NetMotCM disassembly - I think the xchg call to the byte ptr in edi is incorrect // math, causing the invalid pool call: 0: kd> u 80556298 nt+0x7f298: 80556298 35d1c4f798 xor eax,98F7C4D1h 8055629d 84ef test bh,ch 8055629f 86b7c9ff86d8 xchg dh,byte ptr [edi-27790037h] 805562a5 c8ff86ff enter 86FFh,0FFh 805562a9 184e80 sbb byte ptr [esi-80h],cl 805562ac 0000 add byte ptr [eax],al 805562ae 0000 add byte ptr [eax],al 805562b0 d8c8 fmul st,st(0) // NetMotCM looks like a driver compiled just after XP RTM'ed (before SP1, even): 0: kd> lmvm NetMotCM start end module name f7c4b000 f7c4e800 NetMotCM T (no symbols) Loaded symbol image file: NetMotCM.sys Image path: \SystemRoot\system32\DRIVERS\NetMotCM.sys Image name: NetMotCM.sys Timestamp: Mon Feb 25 15:55:17 2002 (3C7AA4B5) CheckSum: 0000ABF2 ImageSize: 00003800 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 I'm going to strongly suggest you update that Motorola driver to the latest version, but I'm also going to suggest you download and install the latest ndis.sys from 918837, just in case. You can request the hotfix from here. The reason I say this is because I've seen this behavior before, on NDIS 4.0 driver code that was ported from NDIS 4.0 to NDIS 5.x (the Motorola driver), and given the age of that driver I'll bet it was originally coded against NDIS 4.0 (especially if the code was originally written to run on Win95 or NT4 - that had NDIS 4.0 only, so drivers had to meet NDIS 4.0 without 5.0 extensions to run there properly). Also, it looks like you have the driver attached over the USB bus (there are some USB calls further down the stack I saw, so I'm making a guess that your surfboard is connected to the PC via USB) - you may want to try using a CAT5 cable and connect it to a real network card if you can, as there are many other posts out there about problems with this driver, only when USB-connected. Upgrade the driver (if possible), and also upgrade ndis.sys to be safe.

Correct As to what to do with this newer version of verifier: 1. Click "Create custom settings", then Next 2. Click "Select individual settings from a full list", then Next 3. Click the box for "Special pool", then Next 4. Click "Automatically select all drivers installed on this computer", then Finish

Well, it extends the schema with the R2 extensions. It's nothing to be worried about, per se, but it is always good to have a backup .

You are correct - you must update the AD schema with the R2 extensions before you can install R2 on any of your DCs.

And, Windows Updates Downloader - gotta use the search box!!!

Try start > run > verifier.exe > click OK Check the box for "Special Pool" Select "Verify all Drivers" click Apply and then Exit Then reboot and see what happens - note that we EXPECT the machine to bugcheck at this point, so making sure that a reboot after a bugcheck is disabled while you're in safe mode is probably also a good idea, to make sure we see the bugcheck when it happens. Once you're done, reboot and cross your fingers .

Did you delete the built-in administrator account? I know it won't help you now on this install , but there's a snippet from an unattend xml file here to enable the admin account during install so that this shouldn't happen again...

A STOP 0xC2 means that this is a bad pool caller bugcheck, so honestly, without driver verifier enabled on the box we won't be able to tell what caused this. Perhaps you can enable that and get another bugcheck, then attach that minidump for us to look at?