cluberti

If you're on a newer build (7068 or higher) you can use resmon to look at the memory and get an accurate picture, just a thought.

It's been asked before, and the answer is currently "no".

You're technically not really doing anything, as on the next reboot Windows will load the kernel and the driver and determine how many cores you have (and configure itself accordingly), so I'm not sure it will do anything at all. The tool was meant to test *reducing* the number of CPUs seen by the box, not to increase it. If this number is lower than the number of cores installed, it'll stick, but if it's higher it'll be reset down to the correct #. It's a troubleshooting tool meant to artificially lower the CPUs available to the system (to test SMP amongst a specific # of processors, or to test an app in UniProc mode, etc), and it won't increase more than the number of cores installed (and supported) by the OS you're using.

I guess I didn't make myself clear - a complete memory dump is going to dump the *complete* contents of memory to disk. Meaning, if you have 3GB of your 4GB of RAM committed in any way, the resulting .dmp file will be 3GB (and you'll need 3GB + ~64K of pagefile to hold it), and it has to be on the partition with the \WINNT folder. Otherwise, the paging file will be corrupt.You could also use a null-modem cable connected to a serial port attached to another machine running windbg, and .dump it over the serial port. That would probably only take about 3 or 4 days to complete .

It is *utterly* important. When the box is crashed, the only volume Windows still has access to is the partition holding the WINNT folder. So if the paging file isn't on that partition, you will not get a .dmp file. The mistake you made is the mistake I see almost everyone make - a paging file with 4GB of RAM really isn't entirely necessary until you have problems, and at which point you'll be in trouble if you didn't size your volume/partitions appropriately to hold a paging file on the Windows volume/partition in the case of an emergency or a need for a crash dump. Anything more than 3GB of RAM in a machine and it will not appear, this is normal. Set the value to 1 and reboot, and it will be set even though it won't show in the GUI. If your machine is still servicing interrupts, pressing down and holding the right CTRL key while tapping the scroll lock key twice causes an interrupt down the PS/2 keyboard, which in turn the kernel will trap and dump the box. That's why a PS/2 keyboard is necessary (USB devices don't cause interrupts like this).

Well, you can always try to take a complete memory dump of the system.

Do you have uphclean installed on that box? If not, you should install it as it's a wonderful troubleshooting tool (logs errors to the event logs).

I thought I already did:

Address 80000006 is a kernel-mode address, unless you've enabled /3GB in your boot.ini. Assuming you haven't, the address is a kernel-mode address and as such is not accessible from user mode (user mode addresses are the first 2GB, 0x00000000 to 0x7FFFFFFF, and kernel mode is the last 2GB, 0x80000000 to 0xFFFFFFFF). However, that looks more like an error code (ERROR_INVALID_HANDLE) than an attempt to read from an address. I'd suggest asking them to debug it, because while the error is because the app tried to read from an address it doesn't have access to, it looks a lot like the application is saying it's encountered the error I mentioned.

That's actually Vista RTM. Vista SP1 and Server 2008, depending on what's in the WIM, will show as 6.0.6001.18000. For example: <VERSION> <MAJOR>6</MAJOR> <MINOR>0</MINOR> <BUILD>6001</BUILD> <SPBUILD>18000</SPBUILD> </VERSION> It won't help you distinguish between Vista SP1 or Server 2008, however. But, you can also look at the following flags to differentiate - Here's Server 2008 Standard (x64) vs Vista SP1 Business (x64): <NAME>Windows Longhorn SERVERSTANDARD</NAME> <DESCRIPTION>Windows Longhorn SERVERSTANDARD</DESCRIPTION> <FLAGS>SERVERSTANDARD</FLAGS> <WINDOWS> <ARCH>9</ARCH>or <NAME>Windows Vista BUSINESS</NAME> <DESCRIPTION>Windows Vista BUSINESS</DESCRIPTION> <FLAGS>BUSINESS</FLAGS> <WINDOWS> <ARCH>9</ARCH> Note that ARCH 9 == x64, and I believe 0 == x86.

IE8 does not install in Win7, because it ships with Win7. If you don't see it, either you're running an "N" version or it's been unchecked in the list found in "Turn Windows Features on or off" section of Control Panel > Programs.

Note it says (April Fool's Day)???

OU == Organizational Unit, in Active Directory's LDAP.

LOL - good questions though. However, note that if someone is thinking of using these in a corporate environment (for reasons that only they could explain), using nLite would be out of the question (the no corporate use in the EULA). However, for a stripped-down home machine, obviously your way makes much more sense. Besides, technically WinFLP was meant as more of a dumb terminal for connecting to TS boxes rather than a "real" OS anyway.

OK, so it's not a kerberos problem. Assuming you don't have a load balancer or firewall between the DCs and clients that artificially times out connections, this is very odd indeed.

Please don't double-post. Leaving the vlite post open, closing this.

I've always felt like that with Photoshop, although if manipulating images is part of your job I can see dropping the coin. Otherwise, paint.net for me.

Actually, CS4 on Vista will try to use the GPU and Aero/DWM to run the app, so the fact that it's designed for DWM means it does actually need at least Home Premium. Any app that uses the new DWM interface APIs won't work on a version that doesn't have the bells and whistles, so to speak, thus leaving editions like Starter and Home Basic out of luck. Now, honestly I've never tried to use Photoshop CS4 on a Vista Home Basic system, but it is possible that "not supported" does not equal "doesn't work", it just may mean that if it doesn't work, don't call Adobe. Technically all levels of Vista support OpenGL rendering if an ICD is installed by the video driver, so it's worth trying I suppose.

.DEFAULT is the system profile (the one you see at CTRL+ALT+DEL. It's not the "Default User" profile.

If you can get access to a build later than the beginning of March (I think 7024 was the first build in March), it'd be interesting to see if it's fixed there.

Going to be almost impossible to say without auditing. It's not an abnormal folder (the allusersprofile is there, for example, amongst other things, so it's been there since you installed Vista), but it usually is hidden. Odd indeed. You could make it hidden again though, that'd be easy to do.

Vista creates it, and it's a default junction. Usually it's hidden - did you unhide it, or allow explorer to see hidden folders?

Post the .dmp file(s) on a file share somewhere and we'll take a look.

It's an I/O problem, so any latent I/O could cause it from what I can tell. It'd be easier to say with a full dump, as a lot of the data isn't here, but what I see matches what I've seen with this in the past on Vista systems, and there was a hotfix (again, above link) released in February to fix it. Knowing that Win7 is still in development, they probably have this in Win7 in builds in March of some timeframe.

It's known to occur in systems doing any power state changes, not just going to sleep or hibernate, and it's also known to happen when mixing IDE and SATA devices (I don't know about pure SATA on a box, for example) or when a SATA controller has devices in IDE emulation mode. Unfortunately we all know KB articles can sometimes be too vague about the problem.