cluberti

Does it look like this? Trying to wrap my mind around this: Member -------- Domain Controller -------- XP box | | 172.16.0.x 10.0.0.x

I am specifically interested in the 401.2 response from your proxy server after the anon request from the client, and what WWW-Authenticate header is sent from the proxy.

You need to know how much RAM your BIOS reserves under the 4GB mark - x86 versions of Windows can only use what the BIOS hasn't reserved (in some cases, 512MB to 1GB). Also, high-end video cards with 256MB or more of RAM generally shadow RAM as well, so most higher-end 256MB cards will reserve 256MB of RAM that Windows can't use, 512MB cards reserve 512MB, etc. It's a good idea to check your motherboard vendor or system vendor's support email or telephone line to find this out if the BIOS doesn't specifically have this documented or in the documentation that came with your PC.

.net versions are not cumulative, although most newer .net apps aren't written against a specific version. However, if you have an app that needs 1.1 or 2.0, you'll have to install those along with 3.0.

I'm guessing if they hadn't made the CDs and SOLD them, they probably wouldn't have drawn ire (or, at least not yet). How is Microsoft not allowing an unlicensed 3rd party to resell their code "pulling crap"? If you resold Citrix hotfixes (for a profit, no less) on CD, would it not be OK if Citrix forced you to stop?

What type of auth is the proxy server using? IE will try to auth with user creds first unless it gets a proxy response specifying auth method - what does a network trace from the client show after the proxy sends the 401?

It depends on how the BIOS reserves it - if it's just shadowed, Vista will use it. If it's actually reserved by the BIOS, Vista will not use it. Shadowed memory is just BIOS information copied to RAM so the system can access it faster, but it's not required. However, if the bios reserves the shadow range, the OS won't see it at all (or it'll see it, but cache the memory so no apps or kernel structures can allocate it).

You aren't blocking tcp port 88 anywhere on the network, are you?

The OS doesn't allocate any RAM specifically to processes, it creates Virtual Address Space for each application (and it's 8TB theoretical on x64, vs 2GB or 3GB on x86) and the memory manager handles whether or not that virtual address space is backed by RAM, pagefile, or both. As to multitasking, there are other benefits that make native 64bit apps faster, like being able to address twice the CPU registers as a 32bit app, your kernel having 128GB for paged and nonpaged pool vs 256MB and 530MB (with 4GB of RAM in the box on boot) for the same pools under x86. File sizes can be larger, larger memory structures can be addressed (although this will take some time as RAM cheapens), and we remove a lot of architecture limitations that home users will be bumping into in the next few years as 4GB of RAM (or more) becomes more common. I know it's somewhat nitpicking, but I really don't see a reason to run an x86 platform at this time unless you have a specific app or piece of hardware that just won't run under x64 properly - this is a reverse of my opinion a few years ago when XP/2K3 x64 was released, where I thought just the reverse. Most newer hardware has x86 and x64 drivers without issue, and almost all x86 applications will run just fine on x64 without modification unless they use kernel-mode filter drivers (antivirus, firewall, etc - and those almost always have x64 versions now) or have a specific architectural design that would preclude x64 (like some Adobe apps).

I don't know - I'm not sure I agree with all of the anti-cert people. I think the MC** certs got a bad name back in NT4 and 2000 due to the ease of which someone could get a cert - however, the 2003 certs were much harder to achieve without real-world experience, and the Vista/2008 certs are *really* quite a bit harder without having good knowledge of the product (crams will be a LOT harder for these than they have been). A cert from someone without experience is generally worthless, but getting one with experience is similar to saying "not only can I do it, the vendor has certified me to this level of proficiency". Not all people see it this way, but when I hire, I choose experience first, and then use certs as a tiebreaker when one needs to be had (at least for the 2003 variants and up). I'm glad that gone are the days when everyone with an MC** cert could easily have been a "paper MCSE". To each his or her own, of course, but certs with experience are valuable in my opinion.

Cool - keep us posted.

First and biggest limitation? App developer using PAE to address memory above 4GB has to map that RAM into a memory window (of configurable size) into the app's process, and do all of the memory management for RAM in that window on it's own (no OS help) - needless to say, lots of apps do this poorly.

No problem - maybe Specas can tell us if removing / upgrading / doing something to the driver in question fixes things.

It's going to scan the CD to make sure the binaries on disk match their hotfix versions (from the OS cache) or the CD versions (from the install media). If the binaries match neither, then yes, it will reinstall from CD.

That is correct. However, UAC should only be invoked when doing system-level work (like reg editing, installing apps, modifying files in \Windows or \Program Files, etc). If everyday applications keep invoking UAC, that means they are doing something in a protected area of Windows, and aren't Vista-compatible. Whether or not the vendor has a Vista-compatible update is another problem entirely, but that's why UAC prompts - your app is doing something it shouldn't be, and Vista wants to make sure you are allowing it. I think NOT having a button to allow always is a good thing (for devs, not users), in that it forces develoopers to write apps that don't have UAC prompts (and are thus safer to run and can run LUA, long term, for end-users).

They handle it because their kernels were compiled with PAE support - able to address memory over the 4GB boundary imposed by the BIOS. It's a hack, at best, and originally meant (by intel) to bridge the gap between 32bit and 64bit (didn't happen as fast as they had hoped ).

Incorrect - a stop 0xD1 is almost always a driver issue, as seen above.

In all of the dumps generated, the faulting driver causing this is nltdi.sys: // The stack of the failure always looks similar to this: kd> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. f8c3e4c4 f6bd4ded 00000000 f8c3e8b7 82489f99 nltdi+0x5220 f8c3e820 f6bd51a5 f8c3e864 00000003 f8c3e920 nltdi+0x5ded f8c3e830 f6bd25e3 f8c3e864 824a7e98 81ce6bf8 nltdi+0x61a5 f8c3e920 f6bfe092 82489ec4 00000016 f8c3e9a0 nltdi+0x35e3 f8c3e9bc f6bfe340 824a7e98 2d963a4e 64c43a4e tcpip!FindListenConn+0x305 f8c3ea60 f6be3ef5 820d2970 64c43a4e 2d963a4e tcpip!TCPRcv+0x2ff f8c3eac0 f6be3b19 00000020 820d2970 f6be6076 tcpip!DeliverToUser+0x18e f8c3eb3c f6be3836 f6c233f0 820d2970 824d86da tcpip!DeliverToUserEx+0x95e f8c3ebf4 f89a4232 820d2970 824d86ee 0000001c tcpip!IPRcvPacket+0x6cb f8c3ec38 f89a42cc 0cabb1e5 824298c8 824d86cc wanarp!WanReceiveCommon+0x164 f8c3ec70 f8496c9f 0cabb1e5 00000000 f7ecfb40 wanarp!WanNdisReceivePacket+0x60 f8c3ecc4 f7eca01d 0066d9c8 8201d9f0 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2 f8c3ecd8 f7eca1b4 824458c0 8201d9f0 00000001 psched!PsFlushReceiveQueue+0x15 f8c3ecfc f7eca5f9 825cddc0 00000000 824458c0 psched!PsEnqueueReceivePacket+0xda f8c3ed14 f8496d40 825cddb8 8210cdc0 81ffc888 psched!ClReceiveComplete+0x13 f8c3ed64 f7ee0c59 0066d9c8 f8c3eda4 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4 f8c3ed98 f7ee0f15 02ffc888 824298c8 81ffc888 ndiswan!IndicateRecvPacket+0x2af f8c3edcc f7ee13c2 81ffc888 824d8670 00000032 ndiswan!ProcessPPPFrame+0x193 f8c3ede8 f7edee51 82002a08 824d8670 8260ecc8 ndiswan!ReceivePPP+0x76 f8c3ee0c f84918f5 00000001 81da5644 00000032 ndiswan!ProtoWanReceiveIndication+0x106 f8c3ee30 f88a0979 f8c3ee58 024b9900 00000001 NDIS!NdisMWanIndicateReceive+0x54 f8c3ee68 f88a5e9d 82018d50 82018ac8 00000000 raspppoe!MpIndicateReceivedPackets+0x93 f8c3ee88 804ff400 f88a8028 f88a7fe0 db258352 raspppoe!TimerEvent+0x7f f8c3efa4 804ff517 99ff4489 0000001a ffdff000 nt!KiTimerListExpire+0x122 f8c3efd0 80540f7d 80552180 00000000 000b2851 nt!KiTimerExpiration+0xaf f8c3eff4 80540c4a b9a54d44 00000000 00000000 nt!KiRetireDpcList+0x46 f8c3eff8 b9a54d44 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a 80540c4a 00000000 00000009 bb835675 00000128 0xb9a54d44 // Looks like netlimiter's driver: kd> lmvm nltdi start end module name f6bcf000 f6be1980 nltdi T (no symbols) Loaded symbol image file: nltdi.sys Image path: nltdi.sys Image name: nltdi.sys Timestamp: Wed Sep 13 18:01:41 2006 (45087FC5) CheckSum: 000144A5 ImageSize: 00012980 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 // The function being attempted at the time of the bugcheck // (I don't have symbols for this, obviously, so I've resorted // to unassembling the function itself to find the culprit): kd> uf nltdi+0x5220 nltdi+0x5220: f6bd4220 8b4904 mov ecx,dword ptr [ecx+4] // failure is here f6bd4223 40 inc eax f6bd4224 85c9 test ecx,ecx f6bd4226 75f8 jne nltdi+0x5220 (f6bd4220) nltdi+0x5228: f6bd4228 5d pop ebp f6bd4229 c20400 ret 4 // Registers showing the failure (trying to read from address // 0x00000008, which will always cause a bugcheck): kd> r eax=00000000 ebx=f8c3e864 ecx=00000004 edx=00000000 esi=81f88158 edi=00000003 eip=f6bd4220 esp=f8c3e4c4 ebp=f8c3e4c4 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210202 nltdi+0x5220: f6bd4220 8b4904 mov ecx,dword ptr [ecx+4] ds:0023:00000008=???????? // Here's why, in assembly math: ecx = 0x00000004 dword ptr [ecx+4] = 0x00000008 ...thus... mov ecx,dword ptr [ecx+4] ... is placing 0x00000008 in the ecx register, and then calling it as the read address. Thus, an attempt to read from memory address 0x00000008, which is in the first 64k of process space and any attempt to read or write from the first 64k causes an access violation. When this happens in kernel mode, the box bugchecks (as it does in your case).

I'd run sfc /scannow on your install, as well as upgrading drivers to the latest WHQL versions if possible. Then, I'd suggest running msconfig to disable all non-Microsoft startup items and services, then I'd run ShellExView to disable all non-Microsoft shell extensions. The errors you are getting state that <some application> attempted to read from or write to a particular memory address (virtual address space, not RAM), and that address passed in by the application (or something loaded within the application's process space) is invalid. A memory dump of the process when the error occurs would help, but generally these are caused by explorer shell extensions or applications loaded on startup (although I've seen some antivirus and firewall packages cause this as well).

HP has utilities to help with Windows setup, and since that's a common IA64 controller, they likely have a utility you can use to setup Windows more easily from the hologram media.

Search before posting - this has been answered before (it's even stickied somewhere). The short answer is no, as this is a hardware limitation that x86 OSes are not able to easily overcome. The solution, if you're going to stay x86, is to use a server-class OS that supports PAE - otherwise, go x64. Again, this isn't a Windows problem, it's an architecture limitation.

It's a self-fulfilling cycle - everyone should run 32bit because the software is all 32bit, so when does everything go 64bit? If everyone runs a 32bit OS, why should a vendor bother writing a 64bit package? 64bit will eventually come upon us, but it'll be forced somewhat, I'm sure.

If the controller attached to those drives isn't battery backed, Vista shouldn't let you enable that setting.

I'm not sure I see anything here that isn't common sense or new, honestly. Those who choose 64bit do so because their hardware, software, and drivers are supported, and those that have components that don't work, find out quickly .

" ldap_bind_s failed with = <81>" That's bad Are the child domains connected to the parent domain via a WAN? If so, make sure the Network Location Awareness service is running on the XP clients, or random problems can happen when binding across a WAN...