cluberti

Reinstall Windows to change a partition name??? That's crazy talk. To the OP, I'm not entirely sure what the problem is, however - are you saying you can't change it from explorer but you can from disk management, or...?

Any particular reason you're using a 64bit WinPE?

Linkie . Add HTA support to your WinPE images, and you can run quick and dirty (or pretty) HTAs in your WinPE environment.

That would be pretty easy to do with a menu and an if / then check. Or, write a quick HTA front-end for it and just run that from your startnet.cmd file.

In the NAS (consumer-grade, anyway) department, to get good and fast, you'll have to omit cheap (good, fast, cheap, select two).

Different vulnerability, but it's not "new" per-se. This new one would have to be modified to affect the way Win9x handles .lnk files for the control panel (specifically control panel .lnk files), because on 2000+ the .lnk must load a .dll and use a specific control panel path which is a bit different in Win9x, it seems. It *could* be done easily, but I doubt with the 9x userbase this would be a useful expenditure of time for a virus writer.

If this is a new installation of Windows, then you'll get new SIDs for every installation. If you're taking an existing install of Windows XP and making an image of it to re-deploy (it doesn't appear from your screenshots that you're doing this, but I figure I'll mention it anyway), using sysprep before capturing the image will (mostly) avoid duplicate SIDs. As to answer files, it's not really important. Here's one of mine you might find useful: [SetupData] OsLoadOptions = "/noguiboot /fastdetect" [Data] AutomaticUpdates = YES AutoPartition = 1 MsDosInitiated = 0 UnattendedInstall = Yes [Unattended] ExtendOEMPartition = 1 Unattendmode = FullUnattended UnattendSwitch = YES OemPreinstall = YES OemPnPDriversPath = drivers\audio;drivers\chipset;drivers\misc\wireless;drivers\modem;drivers\network;drivers\RAID;drivers\touchpad;drivers\video OemSkipEULA = YES TargetPath = WINDOWS Filesystem = ConvertNTFS DUDisable = YES Hibernation = NO WaitForReboot = NO Repartition = Yes [GuiUnattended] TimeZone = 035 AdminPassword = Password1 EncryptedAdminPassword = NO OemSkipWelcome = 1 OEMSkipRegional = 1 AutoLogon = YES AutoLogonCount = 1 [SetupParams] UserExecute="%systemdrive%\temp\unattend.cmd" [UserData] FullName = USER OrgName = ORG ComputerName = * ProductKey = XXXXX-XXXXX-XXXXX-XXXXX-XXXXX [Display] BitsPerPel = 32 Xresolution = 1024 YResolution = 768 [Identification] JoinDomain = DOMAIN DoOldStyleDomainJoin = YES [Networking] InstallDefaultComponents = Yes [WindowsFirewall] Profiles=WindowsFirewall.TurnOffFirewall [WindowsFirewall.TurnOffFirewall] Mode=0 [NetServices] MS_Server=params.MS_PSched [NetOptionalComponents] Beacon = 0 [Components] Accessopt = Off Chat = Off Deskpaper = Off Dialer = Off Fax = Off Freecell = Off Hearts = Off Media_utopia = Off Minesweeper = Off Mousepoint = Off Msmsgs = Off Msnexplr = Off Netoc = Off OEAccess = Off Pinball = Off Solitaire = Off Spider = Off WMAccess = Off zonegames = Off [PCHealth] ER_Display_UI = 0 ER_Enable_Applications = None ER_Enable_Kernel_Error = 0 ER_Enable_Reporting = 0 ER_Enable_Windows_Components = 0 ER_Force_Queue_Mode = 0 ER_Include_MSApps = 0 ER_Include_Shutdown_Errs = 0 [Shell] DefaultStartPanelOff = NO DefaultThemesOff = YES [SystemFileProtection] SFCQuota = 0 [SystemRestore] MaximumDataStorePercentOfDisk = 5 RestorePointLife = 7

No, only one works. However, your .cmd can do any number of things. Perhaps if we knew more about what you were trying to do (and when), perhaps we could help.

It is worth noting what a 0x116 bugcheck means: Bug Check 0x116: VIDEO_TDR_ERROR The VIDEO_TDR_ ERROR bug check has a value of 0x00000116. This indicates that an attempt to reset the display driver and recover from a timeout failed. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 The pointer to the internal TDR recovery context, if available. 2 A pointer into the responsible device driver module (for example, the owner tag). 3 The error code of the last failed operation, if available. 4 Reserved. If you're getting these and updating the driver doesn't help, it is most certainly a hardware problem (not *always* a video card issue, but it is the most likely culprit). According to the dump, the nvidia driver did indeed not respond to the reset request after the timeout occurred: // Stack of the crash showing directx calling out to crash the box on the failure // of the video driver to respond to an adapter reset request: 0: kd> kn # ChildEBP RetAddr 00 81f26cb0 8e9a0adb nt!KeBugCheckEx+0x1e 01 81f26cd4 8e99ac14 dxgkrnl!TdrBugcheckOnTimeout+0x8d 02 81f26d18 8e9a19cb dxgkrnl!DXGADAPTER::Reset+0xee 03 81f26d28 8d6c02c7 dxgkrnl!TdrResetFromTimeout+0x12 04 81f26d3c 8d6c3573 dxgmms1!VidSchiRecoverFromTDR+0x15 05 81f26d50 82a0e6bb dxgmms1!VidSchiWorkerThread+0x7f 06 81f26d90 828c00f9 nt!PspSystemThreadStartup+0x9e 07 00000000 00000000 nt!KiThreadStartup+0x19 // The pool tag address: 0: kd> dc 849863a0 L1 849863a0 52445476 vTDR // Looking at nonpaged pool for the alloc: 0: kd> !pool 849863a0 Pool page 849863a0 region is Nonpaged pool 84986000 size: 78 previous size: 0 (Allocated) NV 84986078 size: 8 previous size: 78 (Free) .... 84986080 size: 40 previous size: 8 (Allocated) NV 849860c0 size: 10 previous size: 40 (Free) NV 849860d0 size: 90 previous size: 10 (Allocated) CcBc 84986160 size: f8 previous size: 90 (Allocated) MmCi 84986258 size: 78 previous size: f8 (Allocated) NV 849862d0 size: c8 previous size: 78 (Free) NV *84986398 size: af8 previous size: c8 (Allocated) *vTDR Pooltag vTDR : Video timeout detection/recovery, Binary : dxgkrnl.sys 84986e90 size: 78 previous size: af8 (Free ) NV 84986f08 size: f8 previous size: 78 (Allocated) MmCi // The bugcheck and it's args (as described previously): 0: kd> .bugcheck Bugcheck code 00000116 Arguments 849863a0 8e41ff80 c000009a 00000004 // 849863a0 == TDR_RECOVERY_CONTEXT // 8e41ff80 == pointer to the device driver // c000009a == error code // Looking further, 8e41ff80 is in the nvidia device driver - note the start/end // address ranges contain this address: 0: kd> lmvm nvlddmkm start end module name 8de0a000 8e911fc0 nvlddmkm (no symbols) Loaded symbol image file: nvlddmkm.sys Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys Image name: nvlddmkm.sys Timestamp: Sat Apr 03 20:37:04 2010 (4BB7DF30) CheckSum: 00B0A9B4 ImageSize: 00B07FC0 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 // And the error code: 0: kd> !error c000009a Error code: (NTSTATUS) 0xc000009a (3221225626) - Insufficient system resources exist to complete the API. // A quick look at the memory overview would indicate that this is not due to an // actual system memory resource problem: 0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 524110 ( 2096440 Kb) Page File: \??\C:\pagefile.sys Current: 2096440 Kb Free Space: 2063756 Kb Minimum: 2096440 Kb Maximum: 6289320 Kb unable to get nt!MmSystemLockPagesCount Available Pages: 365283 ( 1461132 Kb) ResAvail Pages: 478944 ( 1915776 Kb) Locked IO Pages: 0 ( 0 Kb) Free System PTEs: 373448 ( 1493792 Kb) Modified Pages: 22960 ( 91840 Kb) Modified PF Pages: 22959 ( 91836 Kb) NonPagedPool Usage: 9358 ( 37432 Kb) NonPagedPool Max: 386046 ( 1544184 Kb) PagedPool 0 Usage: 21191 ( 84764 Kb) PagedPool 1 Usage: 4347 ( 17388 Kb) PagedPool 2 Usage: 108 ( 432 Kb) PagedPool 3 Usage: 101 ( 404 Kb) PagedPool 4 Usage: 129 ( 516 Kb) PagedPool Usage: 25876 ( 103504 Kb) PagedPool Maximum: 523264 ( 2093056 Kb) Session Commit: 6930 ( 27720 Kb) Shared Commit: 39407 ( 157628 Kb) Special Pool: 0 ( 0 Kb) Shared Process: 1806 ( 7224 Kb) PagedPool Commit: 25892 ( 103568 Kb) Driver Commit: 8280 ( 33120 Kb) Committed pages: 202439 ( 809756 Kb) Commit limit: 1048220 ( 4192880 Kb) Total Private: 93834 ( 375336 Kb) 0e94 WinSAT.exe 22406 ( 89624 Kb) 05e4 svchost.exe 15963 ( 63852 Kb) 03b0 svchost.exe 9256 ( 37024 Kb) 084c explorer.exe 6277 ( 25108 Kb) 01d8 csrss.exe 4978 ( 19912 Kb) 03d8 svchost.exe 4504 ( 18016 Kb) 0424 audiodg.exe 4215 ( 16860 Kb) 08d8 SearchIndexer. 3659 ( 14636 Kb) 034c svchost.exe 3603 ( 14412 Kb) 05d0 svchost.exe 2296 ( 9184 Kb) 0534 svchost.exe 2022 ( 8088 Kb) 01c4 sppsvc.exe 1449 ( 5796 Kb) 0450 TrustedInstall 1442 ( 5768 Kb) 05b0 spoolsv.exe 1161 ( 4644 Kb) 01fc services.exe 1077 ( 4308 Kb) 0478 svchost.exe 977 ( 3908 Kb) 04ec mscorsvw.exe 830 ( 3320 Kb) 07dc nvvsvc.exe 794 ( 3176 Kb) 0288 svchost.exe 769 ( 3076 Kb) 06bc dwm.exe 742 ( 2968 Kb) 020c lsass.exe 642 ( 2568 Kb) 0554 taskhost.exe 612 ( 2448 Kb) 031c svchost.exe 605 ( 2420 Kb) 0994 SearchProtocol 550 ( 2200 Kb) 0770 WUDFHost.exe 407 ( 1628 Kb) 02d0 winlogon.exe 396 ( 1584 Kb) 08c4 svchost.exe 302 ( 1208 Kb) 0194 csrss.exe 301 ( 1204 Kb) 02e8 nvvsvc.exe 282 ( 1128 Kb) 0214 lsm.exe 280 ( 1120 Kb) 01cc wininit.exe 266 ( 1064 Kb) 0ea0 conhost.exe 260 ( 1040 Kb) 09b0 SearchFilterHo 252 ( 1008 Kb) 0638 svchost.exe 179 ( 716 Kb) 010c smss.exe 68 ( 272 Kb) 0004 System 12 ( 48 Kb) The only thing left would be a memory issue on the card itself, which would make more sense. I see WinSAT was running, which does test the timeout/resume of the video driver (and thus, the card itself), and any hardware or software failures there will cause a bugcheck (you'd probably get the same sort of crash after hibernating or perhaps even entering standby for a long period of time). You can take a look here as well for some video adapter stress testing techniques as well, although if it was working fine for awhile with this particular card and then just started failing, and you've since already done a driver upgrade, the hardware is the 1st place to look for suspects. It's not likely at this point that it's the driver, although it's always worth investigating if you want to be thorough.

Teleconferencing is still designed for the people who pay for it's use, and that's businessmen and women talking across the miles. Latency isn't a real problem when you're just talking, only more of a minor annoyance (and really cannot be avoided given the design of the protocols and networks it runs on top of).

You've told it NOT to automate your disk setup right there - try these instead: [Data] ... AutoPartition = 1 ... [Unattended] ... ExtendOEMPartition = 1 Filesystem = ConvertNTFS Repartition = YES ... This will tell setup to automate partitioning, remove any existing partitions and repartition with one large partition/volume, and make sure it's the size of the drive (or as large as an NTFS filesystem can be).

Sysdiff might be good, but it has some limitations (notably no 64bit support). Something like regshot or procmon (or both) would be a better set of tools to watch on newer systems like XP, Vista, or Win7.

If you got rid of the Program Files (x86) folder, the following 32bit apps (at the least) would not work: Internet Explorer (and any apps that rely on it's engine) Windows Media Player (or anything relying on it's codecs) InstallShield installers that require anything in the \Common Files subdirs to be there Help in 32bit apps ADO/OLE32 in 32bit apps .NET apps that are 32bit 32bit Windows Sidebar applets Virtual PC There are probably more, but these are a few that would stop working if you did this.

When you say custom image, what was custom about it, and did you add any drivers to the image? Usually I see this when an x86 driver is added to an x64 image (or vice-versa), but there can be other reasons.

I'd configure your system for a complete memory dump, and let's see what's happening. Honestly, if this continues, I'd remove the 1GB of RAM you added and see if the problem subsides.

1: kd> kn *** Stack trace for last set context - .thread/.cxr resets it # ChildEBP RetAddr 00 9aeaac4c 924fe0f3 win32k!CheckForMessageAccessCrossIL 01 9aeaac70 924fe0a8 win32k!CheckProcessIdentity+0x2d 02 9aeaac88 924a92ac win32k!xxxWrapRealDefWindowProc+0x16 03 9aeaace8 924fe074 win32k!NtUserfnINOUTLPWINDOWPOS+0x5f 04 9aeaad20 81a8cc7a win32k!NtUserMessageCall+0xc6 05 9aeaad20 774d5e74 nt!KiFastCallEntry+0x12a WARNING: Frame IP not in any known module. Following frames may be wrong. 06 0327f01c 00000000 0x774d5e74 1: kd> dds 9aeaab50 9aeaabc4 9aeaab50 00000050 9aeaab54 eed737c5 9aeaab58 00000000 9aeaab5c 9aeaabdc 9aeaab60 00000002 9aeaab64 00000000 9aeaab68 eed737c5 9aeaab6c fe6048e8 9aeaab70 9aeaac70 9aeaab74 08214d55 9aeaab78 86168c98 9aeaab7c 00000000 9aeaab80 c0776b98 9aeaab84 eed737c5 9aeaab88 86168c80 9aeaab8c 00000000 9aeaab90 00000000 9aeaab94 00000000 9aeaab98 81a1670c hal!KfLowerIrql+0x64 9aeaab9c 00003bb0 9aeaaba0 9aeaabbc 9aeaaba4 9aeaabc0 9aeaaba8 92509e7e win32k!HANDLELOCK::vLockHandle+0x80 9aeaabac 00000000 9aeaabb0 00000000 9aeaabb4 ff800470 9aeaabb8 00000000 9aeaabbc 00000000 9aeaabc0 9aeaabf4 9aeaabc4 9aeaabdc 1: kd> r eax=803d1120 ebx=00000000 ecx=81b42200 edx=000000ec esi=803d113c edi=00000000 eip=81ada38d esp=9aeaab50 ebp=9aeaabc4 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000206 nt!MmAccessFault+0x10a: 81ada38d 8b03 mov eax,dword ptr [ebx] ds:0023:00000000=???????? We don't really know anything about the user-mode portion of this stack, given your system is only configured for a kernel dump (and not a complete dump), but we do know the crash happened as a result of something that happened in explorer.exe, and we do know further that this occurred in a function used by win32k.sys to try and post a message to another thread, and on top of that we also know they are running in the same desktop (user session) by the usage of CheckForMessageAccessCrossIL (this function wouldn't be called if the message was to be posted to a thread in a process in another desktop session). However, there are PFNs missing from this dump that *should* have memory information available, so either there *is* a memory problem on this machine, or it was just that busy at the time of the dump that it is actually missing data. Obviously an attempt to MOV a 0x0 address into another valid address is going to give you an access violation, and because this is happening in kernel mode (nonpaged pool, to be exact) any page fault here is going to cause a bugcheck. In looking at the pool allocation referenced by the bugcheck: 1: kd> !pool eed737c5 Pool page eed737c5 region is Unknown eed73000 is not a valid large pool allocation, checking large session pool... eed73000 is freed (or corrupt) pool Bad allocation size @eed73000, too large 1: kd> !poolval eed73000 Pool page eed73000 region is Unknown Validating Pool headers for pool page: eed73000 Pool page [ eed73000 ] is __inVALID. Analyzing linked list... Scanning for single bit errors... None found It does appear this is an invalid memory address (it will show up as unallocated in this dump). It's a valid kernel-mode address, and where I'd expect nonpaged pool to contain, so the fact the nonpaged pool is invalid leaves us with three possible scenarios right now - one, it really was freed, and this is a double-free by a driver or kernel extension causing the bugcheck; two, the problem software is trying to read from a pool allocation that isn't really a valid pool address; or three, you do, in fact, have bad memory thus causing a valid PFN to point to a physical block of memory that is corrupt or invalid. All three are obviously bad, but only one can be fixed without an RMA of hardware . At this point, I would suggest a memory test, but I'd also consider when this started happening, and at that point try to figure out if *anything* on the system was changed, updated, etc.

Well, a quick way to at least get an idea would be to look at the source of a page containing a link you expect to work incorrectly - is it a straight href, or does it run script or perform some other function? At least let's start with looking.

KB Article???

I'd rebuild the image in a "lab" VM and check device manager before you sysprep, including hidden devices (open a cmd prompt, run "set devmgr_show_nonpresent_devices=1", then from the same cmd prompt run "devmgmt.msc", then in device manager click view > show hidden devices. After that, scour the tree to see if it is actually installed, because I verified on a VM if I install tightvnc, I install that driver. It's not a default driver in Windows (not even an MS driver), so something in your build seems to be installing it - dfmirage actually has it's own SDK, so it is likely that you're installing something on your build that has used this.

If the problem is with clicking links on a page after you've explicitly visited https:// site.tld, then the problem is with the site itself, not the web server. It sounds like the page isn't using relative hrefs for links.

You can do this in group policy, yes.

Do you have any .dmp files in your Windows directory or the minidump folder inside the windows directory? There can be many reasons, without seeing the dump that was (hopefully) generated from one of these it'll be hard to say.

It's not Windows reporting the error, I believe that's the BIOS. Windows has no control if the BIOS usurps the boot process. I'm moving this to the hardware forum.

Good. As for service packs for Server 2003, they are cumulative. You only need to slipstream SP2.