cluberti

Is this the article you were following to set that up? http://support.microsoft.com/default.aspx?...kb;EN-US;151981

STOP 0xA can be hardware, but the actual STOP error is caused by a driver, usually in DPC/Dispatch IRQL or higher (http://ext2fsd.sourceforge.net/documents/irql.htm), causing the scheduler to have to be invoked - either because the driver's query caused a page fault by trying to access nonresident memory, or by requiring access to a different thread (or needing to start an additional thread). Either of these things cause a STOP 0xA, because at DPC/Dispatch or higher, the scheduler cannot be invoked (this causes the illegal operation error in the kernel that leads to the STOP 0xA). It could be hardware, but I'd say the driver is where I'd start. 818501: How to debug a system after you receive Stop Error IRQL_NOT_LESS_OR_EQUAL (0xA) http://support.microsoft.com/default.aspx?...kb;EN-US;818501 These are the kinds of things that are avoided by using WHQL drivers (see, WHQL drivers aren't just another useless verification acronym ).

You can use perfmon to look at the Process > Page File Bytes counter for a process to see how much of the paging file, in bytes, a particular process is using. Note that the numbers in task manager and perfmon (or any other tool, for that matter) aren't entirely correct, because they'll include portions of memory that are listed as "paged", but are actually still in memory (just ready to be paged out as memory load increases). You can see some of this in the Process > Working Set counter for a process, but again, it's not entirely accurate. For the purposes of your test, the Page File Bytes counter should be close enough to accurate, however.

This gets asked quite frequently here: http://www.google.com/search?q=copy+i386+site%3Amsfn.org

http://www.emboot.com/

This list shows pictures from the Windows\Wallpaper directory and your "My Pictures" folder. Remove files from either of these locations, and the list will shrink.

If you click Start > Run and type services.msc and click OK, can you see if the Help and Support service is listed as running?

Same as with 32bit - XP is limited to 2 processors for licensing reasons, not technical (same as the 10 inbound connection limit). However, processors are licensed per socket, not per core. Therefore, dual proc dual core will indeed yield 4 processors in Windows XP, x64 or x86.

Windows XP x64 is limited to two processors, but it counts by socket, not by core. Therefore, two dual-core processors would show up and work properly as 4 processors in Windows XP x64. However, if you install XP x64 on a machine with 4 (or more) physical processors, you'll onlly see and be able to use two.

np

The manual way, very easy: http://www.microsoft.com/technet/prodtechn...y/mgrtfset.mspx The more automated way, not as easy, but quite powerful: http://www.microsoft.com/windowsxp/using/s...november19.mspx

Not a problem - hopefully we were able to help you.

1. I work as a debugger (amongst other things) at Microsoft. 2. I use windbg, one of the debuggers in the Debugging Tools for Windows package. Edit - The debugging tools are here: http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx

I second Roguespear - this has been asked many times before. I will answer your question, but next time do look harder. The .sif file needs to be in the \\server\reminst\setup\images\<language>\<image>\i386\templates folder. However, RIS .sif files have lots of things in them (that you need) that you won't already have - I strongly suggest merging your .sif file with the existing ristndrd.sif file already in the Templates folder, then restarting the binlsvc service (net stop binlsvc && net start binlsvc).

OK, here goes: Mini062706-01.dmp ---------------------- Stop 0x8E (KERNEL_MODE_EXCEPTION_NOT_HANDLED_M) A driver on the system caused an access violation while you were running an application's setup.exe file. The driver appears to have tried to do an ObfDereferenceObject command through a kernel-level driver (the fault occurred while code was executing in ntkrnlmp), which ultimately caused a bugcheck in the PspExitProcess function at offset 8c. I would need to know what you were actually attempting to install at the time of the bugcheck. Mini062706-02.dmp ---------------------- Stop 0x19 (BAD_POOL_HEADER) It appears that the klif.sys driver file attempted to free kernel pool memory allocated, and the virtual memory block attempted to be freed was either invalid or contained corrupt data, causing the bugcheck. Since a !pool of the address referenced is unknown, it is likely that the driver attempted a free on a block that was unallocated or already freed - I also noticed that the driver attempted to free an allocation size larger than the other allocations in this region, which would also have caused a bugcheck or at least a serious error, had there actually been a memory block to free. This would indicate an issue with the klif.sys driver file - note klif.sys belongs to Kapersky's Antivirus package. Mini062806-01.dmp ---------------------- Stop 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) This one is a mystery, but it does show a pattern - a driver belonging to a non-Microsoft application running inside a svchost.exe process (an application that has a service associated with it) tried to read a memory address that was invalid, and it also did so at an invalid IRQL (IRQ Level) - so if the memory address HAD been valid, the driver still would've bugchecked. I can't tell what driver it was in a minidump, because the driver attempted to reference the memory address it was loaded in (causing corruption, and thus I cannot read anything but ???? in that address). Mini062806-02.dmp ---------------------- Stop 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) This one was easy, as there was no memory corruption - the Intel e1000 NIC driver attempted to write to a kernel memory address using an IRQL that was too high, causing a system bugcheck. I know it was the Intel from the stack on processor 0, showing the bugcheck: ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 819717c7 f309ec1d 8189faa8 00000016 f8962738 0xf8962843 f8962754 f309eecb fe9ac3a8 2660a853 0400000a tcpip!FindListenConn+0x305 f89627f8 f3094ef9 816f4008 0400000a 2660a853 tcpip!TCPRcv+0x2ff f8962858 f3094b19 00000020 816f4008 f3097076 tcpip!DeliverToUser+0x18e f89628d4 f3094836 f30d4210 816f4008 fec71008 tcpip!DeliverToUserEx+0x95f f896298c f3093922 816f4008 fec7101c 0000001c tcpip!IPRcvPacket+0x6cb f89629cc f309817b 00000000 fec71008 fed33720 tcpip!ARPRcvIndicationNew+0x149 f89629fc 8198f095 fed34d68 fec71008 fed33720 tcpip!ARPRcv+0x42 f8962a94 f837088f fed34d68 81607560 815ee00a 0x8198f095 f8962a60 81990329 fe95401c 00000000 00000000 NDIS!ethFilterDprIndicateReceivePacket+0x347 f8962a94 f837088f fed34d68 81607560 815ee00a 0x81990329 f8962afc f4eca01d 00796c78 813e8508 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x347 f8962b10 f4eca1b4 81777ad0 813e8508 00000001 psched!PsFlushReceiveQueue+0x15 f8962b34 f4eca5f9 813e4568 00000000 81777ad0 psched!PsEnqueueReceivePacket+0xda f8962b4c f836fd40 813e4560 816a7008 00000001 psched!ClReceiveComplete+0x13 f8962b9c f828e5aa 00796c78 f8962bdc 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4 f8962cec f828f367 006a7008 f8962d1b 8185ea50 e1000325+0x5aa f8962d10 f8365f09 006a7008 80562f00 f87cf9c0 e1000325+0x1367 f8962d28 804dd26b 816a7470 816a745c 00000000 NDIS!ndisMDpcX+0x21 f8962d50 804dd14b 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61 1: kd> db 8189faa8 8189faa8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fab8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fac8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fad8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fae8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189faf8 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fb08 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 8189fb18 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? start end module name f828e000 f82abc00 e1000325 (no symbols) Loaded symbol image file: e1000325.sys Mapped memory image file: C:\symbols\e1000325.sys\3ECB56BA1dc00\e1000325.sys Image path: e1000325.sys Image name: e1000325.sys Timestamp: Wed May 21 06:36:42 2003 (3ECB56BA) CheckSum: 0001EFDA ImageSize: 0001DC00 File version: 7.0.37.0 Product version: 5.1.2600.0 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.6 Driver File date: 00000000.00000000 Translations: 0000.04b0 CompanyName: Intel Corporation ProductName: Intel(R) PRO/1000 Adapter InternalName: E1000325.SYS OriginalFilename: E1000325.SYS ProductVersion: 7.0.37.0 FileVersion: 7.0.37.0 built by: WinDDK FileDescription: Intel(R) PRO/1000 Adapter NDIS 5.1 deserialized driver LegalCopyright: 1998-2003, Intel Corporation All Rights Reserved. At least that one wasn't corrupted all to hell. Mini062806-03.dmp ---------------------- Stop 0x8E (KERNEL_MODE_EXCEPTION_NOT_HANDLED_M) Another relatively easy one; a litte corrupt, but still has salvageable data. A kernel mode driver attempted to access a portion of memory that it was not allowed to, causing an unhandled exception in the kernel. This driver appears to have been called by alg.exe, which is the application layer gateway service. This is another error related to the network stack, and since a kernel driver is involved, the only kernel driver here in the dump on the network stack is the Intel driver... (see a pattern???) Mini062806-04.dmp ---------------------- Stop 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) Yet another Stop 0xD1 caused by the Intel e1000 driver. I'd say you've either got issues with your RAM, or the Intel driver is buggy - and no, the below is not a copy and paste of the above 0xD1: ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. f8962a94 f837088f ff16a110 81631a38 8161b00a 0x8198926e f8962afc f339901d 006e8408 ff6ba760 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x347 f8962b10 f33991b4 81871ad0 ff6ba760 00000001 psched!PsFlushReceiveQueue+0x15 f8962b34 f33995f9 81892dc0 00000000 81871ad0 psched!PsEnqueueReceivePacket+0xda f8962b4c f836fd40 81892db8 81892008 00000001 psched!ClReceiveComplete+0x13 f8962b9c f79c25aa 006e8408 f8962bdc 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4 f8962cec f79c3367 00892008 f8962d1b 8183d130 e1000325+0x5aa f8962d10 f8365f09 00892008 80562f00 f87cf9c0 e1000325+0x1367 f8962d28 804dd26b 81892470 8189245c 00000000 NDIS!ndisMDpcX+0x21 f8962d50 804dd14b 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61 f8962d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28 1: kd> db ff16a110 ff16a110 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a120 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a130 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a140 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a150 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a160 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a170 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ff16a180 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? start end module name f79c2000 f79dfc00 e1000325 (no symbols) Loaded symbol image file: e1000325.sys Mapped memory image file: C:\symbols\e1000325.sys\3ECB56BA1dc00\e1000325.sys Image path: e1000325.sys Image name: e1000325.sys Timestamp: Wed May 21 06:36:42 2003 (3ECB56BA) CheckSum: 0001EFDA ImageSize: 0001DC00 File version: 7.0.37.0 Product version: 5.1.2600.0 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.6 Driver File date: 00000000.00000000 Translations: 0000.04b0 CompanyName: Intel Corporation ProductName: Intel(R) PRO/1000 Adapter InternalName: E1000325.SYS OriginalFilename: E1000325.SYS ProductVersion: 7.0.37.0 FileVersion: 7.0.37.0 built by: WinDDK FileDescription: Intel(R) PRO/1000 Adapter NDIS 5.1 deserialized driver LegalCopyright: 1998-2003, Intel Corporation All Rights Reserved. The pattern is staggering - what happens if you uninstall the Intel software and disable or remove the NIC? I'd bet the problem would go away...

Have you seen this KB?: http://support.microsoft.com/?kbid=331988&sd=RMVP Worst case scenario, make sure your computer is configured for a complete dump, and analyze the resulting .dmp file the next time it happens (or PM me and I'll do it). However, first make sure you've got the latest Service Pack for your OS and the latest WHQL USB drivers, as this is 99% of the time a USB driver problem. 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties"; this will open the "System Properties" window. Go to the "Advanced" tab and click "Performance Options". Click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB. 3. Also in the "System Properties" window, click on the "Advanced" tab, then click "Startup and Recovery". Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 3a. If the "Complete Memory Dump" option in step 4 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 5. You will need to reboot for these changes to take effect. 6. The next time the box bugchecks, you should now see your server dumping physical memory, then rebooting. When it reboots, it'll create a file called "memory.dmp" - this file will tell you (or us) what happened, and why. Again, make sure you've got the latest SP and USB drivers, as this is 99% of the time a USB driver problem.

To all - this has been discussed to death, and there's no "right" answer unless you want to do a memory dump. However, Windows does have a portion of kernel memory that, if needed, can be paged out to disk in the pagefile. If the pagefile doesn't exist, it'll either a. create it and page out the kernel, or b. fail to create it (timing issue) and you'll bugcheck. If you've got 1GB of RAM or larger, you won't hurt Windows by not running a paging file - it won't help much, but it certainly won't hurt in most situations. I suggest all purchase and read "Windows Internals 4th Edition" (http://www.microsoft.com/MSPress/books/6710.asp), then make informed determinations for yourself.

This can be done prior to Windows installation with a WinPE disk and diskpart. I don't see the need to pay for the ability to do something I can already script for free .

I've never had luck partitioning in RIS either - I first boot to WinPE in RIS, have a script that runs diskpart.exe to create the drive and format it, then kick off the Windows setup from there. I think that's the most reliable option, but someone else may have some suggestions.

If you don't understand how to modify the ARC path in boot.ini, I wouldn't suggest this...

If drag and drop or copy and paste (or both) fail, it's almost always a problem with OLE. If you've got a machine that is working, you can do the following to get this one fixed: 1. Open DCOMCNFG tool from a working machine, and connect to the problem machine. - In dcomcnfg -> Component Service -> Computers -> right click -> New -> Computer 2. Type the failing machine's name 3. Right click problem machine's name, click properties 4. Go into the Default COM Security tab, select Edit Default for Access Permissions 5. Make sure Self and System are present with Access Permissions to Allow - any other accounts should be removed 6. On the same tab, click on Edit Default for Launch Permissions and check to make sure you have Administrators, System, and Interactive with Allow permissions 7. Export HKLM\Software\Microsoft\Ole key from the working machine 8. Import the Ole key into the non-working machine, and reboot This should get you up and running again.

It would, but you need to make sure that each client uses the site's DNS server as the primary, but uses one of the other sites' DNS servers as secondary. Otherwise, they won't know how to access other DCs at other sites without a working DNS server.

http://technet2.microsoft.com/WindowsServe...3.mspx?mfr=true

http://support.microsoft.com/default.aspx?...;302969&sd=tech