cluberti

The STOP 0x77 and 0x7A events both state you're having hard disk failures. From the help file in windbg, it lays out what is happening when you start getting these types of bugchecks with this error code: KERNEL_STACK_INPAGE_ERROR (77) The requested page of kernel data could not be read in. Caused by bad block in paging file or disk controller error. In the case when the first arguments is 0 or 1, the stack signature in the kernel stack was not found. Again, bad hardware. An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates the data could not be read from the disk due to a bad block. Upon reboot autocheck will run and attempt to map out the bad sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging file is on a SCSI disk device, then the cabling and termination should be checked. See the knowledge base article on SCSI termination. Arguments: Arg1: c000009c, status code Arg2: c000009c, i/o status code Arg3: 00000000, page file number Arg4: 0592a000, offset into page file Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc000009c - STATUS_DEVICE_DATA_ERROR DISK_HARDWARE_ERROR: There was error with disk hardware

If it was being downloaded by the Windows Update service, then it is being downloaded via the BITS service, which supports resuming (it's the reason the service was created - to trickle down Windows Updates to people with slow/intermittent connectivity).

Check your PM please.

If you're talking about antivirus for scanning inbound email messages inside Exchange, yes, you need a product that uses the Exchange VSAPIs. A regular Windows antivirus program will scan the OS, but not the store. There are lots of antivirus applications out there, but I personally use GFI's MailSecurity suite, which has 4 antivirus engines plus antispam and some other features and it cost me about what I was paying just for Symantec's Exchange package previously, and it seems to work at least as good, if not better.

You also have to remember that you have 128MB available of "RAM" in the virtual machine and 512MB of RAM in the physical box. Are the paging file sizes the same, and can you test it in a VM with 512MB "RAM" and the same paging file (I know that requires another machine or adding RAM to that box, but it's the only way to have an apples-to-apples test). The amount of RAM and the paging file modifies the memory manager's commit bias, so you can have 40MB of RAM used on a 128MB box, but the paging file gets committed quite a bit, whereas a 512MB box shows 80MB of RAM used, but almost nothing in the paging file. I would suggest doing this on both your virtual and real machines, to see what amounts of "RAM" you're actually using in the VM, and in the physical machine.

The servicing engine changes make slipstreaming the current SP1 package impossible. This is expected to be fixed in SP2, although I'm not sure if it'll require SP1 media to slipstream it or not (the servicing changes will come in SP1, from what I understand, so I'm not sure if you'll need actual SP1 media to slip SP2, or just a machine running SP1...).

Yes, that will be the build number for Vista SP1 and Server 2008 RTM.

No, YOU lost access to your 32bit IE, and I'm not sure why (don't speak in generalities when there's no way everyone in the world will install IE7 and have problems with the 32bit browser). And yes, IE7 is 32 and 64bit (otherwise how would you have both on Vista x64?). If you manually do a start > run > c:\program files (x86)\Internet Explorer\iexplore.exe, do you see an iexplore*32.exe in task manager?

Not only that, but why bother with DOS boot disks nowadays when recovery CDs that can read/write NTFS drives and copy files over the network are commonplace? Why do things the hard way ...

Vista SP1 cannot be "slipstreamed" to an offline Vista image (and that includes the RTM install.wim from the Vista CD): Maybe it can be hacked in, but SP1 will not be slipstream-able. Rumor has it that future service packs will be.

What? You would eschew privates that are service-pack only, or not integrate the latest service pack (but you would integrate a previous service pack)? Or are you just complaining about the SP3 beta, and will integrate and upgrade to SP3 when it is released?

No, he's talking about the POP3 service that W2K3 offers. There's a document on technet that explains the service, and how it differs from Exchange POP3. Good read, and will answer your questions.

If you have a restore point to when you remember it working, I would try reverting back to that point before doing anything else. However, you could also try uninstalling and reinstalling the software (and drivers) that came with your camera as a start, as this fixes a lot of driver issues similar to the one you're experiencing as well.

You might as well go on vacation, that 10TB volume will take at least a week to chkdsk. Why do you have a volume that large anyway - you would be FAR better served by using mount points on a smaller volume to make up the 10TB (in terms of disk defragmentation time/speed/effectiveness, chkdsk speed/effectiveness, etc).

As long as the modem is a hardware modem (not a winmodem) and Windows 2003 has a driver for it, fax should work with it. The only gotcha is that Windows' built-in fax product is awful .

I'm not sure what your budget is, but what kind of firewalling do you want to do? Do you need inspection of the packets passing through to the web servers, or are you just hoping to punch holes in certain ports on certain IP addresses and that's all you need? If they're windows web servers, ISA 2006 is a good choice as it can do all kinds of good packet inspection and port filtering/port remapping, etc, but if you just need a device to block all but specified ports, a SonicWall or WatchGuard should be more than sufficient (and probably cheaper).

If you request it via the online submission link and specify Win2K, you may be able to get the hotfix. However, since it isn't a security update, and it was released after W2K dropped into extended support, there's no guarantee. https://support.microsoft.com/contactus2/em...t.aspx?scid=sw;[LN];1414&from=KBHotfix&WS=hotfix

If all you are trying to do is integrate hotfixes and application installs into your OS build, I prefer hfslip.

You'll still have to enter creds, but just copy the shortcuts to the "startup" folder in your start menu.

You need Vista business, enterprise, or ultimate to join a domain. Otherwise, no go.

If you download autoruns and shellexview and disable all non-Microsoft items, then reboot, does the problem go away? Also, do you happen to be running nvidia drivers on your machine? Something is starting likely via a rundll32 call that is trying to use an API that is no longer in kernel32. I've only seen this on XP systems with nvidia drivers installed, and updating the driver set usually fixes it.

Well, the MEMORYSTATUSEX is volatile, although in a PE environment it should stay quite stable - however, it's not going to "see" anything reserved by the BIOS for devices, shadowed memory, etc - 3.2GB on a 4GB system sounds fairly accurate (most of my machines report 3.5GB when I use GlobalMemoryStatusEx to query memory). Also, you can use Win32::SystemInfo::MemoryStatus to query RAM, but that ultimately calls GlobalMemoryStatusEx, which uses a MEMORYSTATUSEX structure to grep the ullTotalPhys - so, you're better off using an x64 PE, or living with the x86 limitations, as there's no way short of a direct call to the BIOS in assembly to get this kind of info in a more accurate manner.

Yeah, I'd set up for and gather a dump of it occurring, unless you want to go through the trial-and-error of using autoruns and shellexview to disable all 3rd party (non-Microsoft) extensions, reboot, and re-enable one at a time to figure it out.

Got an adplus crash dump of it happening we can look at?

No, you miss the point. It's 2GB for the kernel (again, virtual address space) and 2GB of VA presented to EACH process running on the machine. Each process "sees" the 2GB (or 3GB, with /3GB) of VA that is presented to it by the memory manager, but this is VIRTUAL, it's just a construct. The application commits memory into it's *virtual* address space, oblivious to whether or not that "memory" is physical RAM or the pagefile (or both). The memory manager then decides where to put those pages the application is using - it either maps them to physical RAM, or puts them in the pagefile (or again, both, in pagefile-backed allocation scenarios). I suggest reading chapter 7 of the Windows Internals 4th edition book if you're still confused. Remember, this is VIRTUAL memory an application sees, and it's not RAM at all. EACH application gets the same 2GB or 3GB of VA, but the actual PHYSICAL RAM that the machine can logically address is 4GB on x86, period (that is 2 to the 32nd power, or 4096).