Jump to content

cluberti

Members
  • Posts

    33
  • Joined

  • Last visited

Everything posted by cluberti

  1. While you've said the ISO is fine, I'd say Windows says something is amiss: C:\Users\Carl>err 80070570# as an HRESULT: Severity: SUCCESS (0), Facility: 0x4c5, Code 0xc7aa# as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x570# for hex 0x570 / decimal 1392 : ERROR_FILE_CORRUPT winerror.h# The file or directory is corrupted and unreadable.# 1 matches found for "80070570"
  2. As long as it's downloading the updates from the catalog and not shipping them directly with the tool, it's fine. If you redistribute in any way (other than just a tool to download them for yourself), that's where you go into copyright and redist problems.
  3. I've replied to your PM - in the interim, it might be best to post instructions on how to go about doing this with a user's own ISO. Going through the process with Microsoft's legal folks will take time, and there's no guarantee that copyright permission will be granted. Good luck though - it'd be cool if you could swing this. If not, there are lots of ways to do this otherwise.
  4. I am the friend, and I assure you I get it. Hosting Microsoft code (whether that be Windows 7 ISOs, hotfixes, downloadable content, etc) would indeed not be legal. However, the reason I pointed out the updates ISO is because it's not that difficult to integrate updates yourself into your own code and recreate your own "updated" ISO.
  5. You haven't done all the steps necessary to make it work. See this KB article (it's for Vista, but applies to Server 2008 as well): http://support.microsoft.com/kb/942956
  6. This is what perfmon is for - specifically, the memory counters listed under the Process section. In looking at your process explorer output screenshot it would seem to indicate Avast, but that could just be a red herring (working set isn't very high for any one process, and Virtual Size counts both committed and uncommitted (just reserved) memory allocations made by the process. The only true way (short of uninstalling things and putting them back one at a time) to figure out memory leaks is to use perfmon and use the object counters under Process first to see which process you should be investigating, and what type of memory allocations it's using.
  7. Looks like windrvr6.sys is attempting to pass the pointer from rdi+0x34 to ecx - problem is, rdi is 0x0 - this is going to access violate. Since it's a kernel driver, this will cause a bugcheck. I'd get with the makers of windrvr6.sys (http://www.jungo.com/st/windriver_usb_pci_driver_development_software.html) to see what they think of this. You probably want to get a complete dump this time though.
  8. These all appear to be classic memory corruption problems - pages from RAM missing/corrupt causing PFN lookup errors, calldriver failures, Working Set trim failures, PoolTag free failures, and even a memory access violation in csrss.exe that caused one of the dumps. If both sticks work one at a time (and you've tested them both in another known working machine together to verify they don't cause the problems with each other), then you've got a problem with the motherboard in that system and it should be replaced. By the way, that is the motherboard in an EQS M64K9-ALV system from EQS Limited (out of business it seems), and it's an ATI Radeon M200 chipset. http://ati.amd.com/products/certified/eqs-mb.html
  9. You do get what you pay for - the case will be fine, but if you build a machine again in the near future re-consider the Cosmos 1000.
  10. You could always run resmon and make sure it is being flagged as "hardware reserved" - if so, you'll at least know it's the BIOS (and probably your onboard video).
  11. You could use resmon to get a high-level overview of memory usage (and that may be enough), but if not you're gonna have to use perfmon.msc and utilize the Process objects for "<All Instances>" (not "_Total"!!!), specifically the handle count, pool nonpaged bytes, pool paged bytes, private bytes, virtual bytes, working set, and working set - private.
  12. If you want to see a breakdown of memory usage, run resmon (Resource Monitor). As of RC1 it breaks down where all of your installed memory is allocated, even showing what is taken by hardware.
  13. Have those folders ever been on an encrypted volume? It's complaining about a thumbs.db file with an encrypted alternate data stream. So, either they were on a volume that was encrypted, or they're potentially a candidate for scanning for malicious data. In any case, if you can boot into ubuntu with the ntfs-3g package, you will be able to delete it. However, due to the encrypted ADS, you will not be able to whack it from within Windows (and without ntfs-3g, probably not get it from ubuntu either).
  14. This is a known issue with XP x64 (and 2003 x64) if you have S4 enabled in your ACPI BIOS.
  15. Are you able to open explorer and have it stay open for any length of time? Usually if you're getting an error in shdocvw, you have a CLSID file type handler or MIME type issue (shdocvw = SHell DOCument VieWer control). If you can boot up in safe mode, I'd download and run autoruns from sysinternals to disable anything non-Microsoft, and do the same when running ShellExView from nirsoft.net. You might also want to run an sfc /scannow to make sure all of the files on your box are kosher - but yes, shdocvw is crashing but likely because something is trying to load and failing, making it the victim (and hiding the source of the problem).
  16. 2 things: 1, click the "click here" link the next time you see this, and post that screenshot here 2, Follow the instructions here to configure your machine to get a "Memory dump from an application/process that is CRASHING", then .zip or .rar the files and upload them somewhere we can access them.
  17. Well, no, but perhaps you could describe in more detail what the problems you are having are, exactly?
  18. Well, you'll get a minidump of that, but definitely not a kernel or complete dump (24GB != 1GB - the "minimum" size for the pagefile is what is allowed for use when dumping, not the max, one of the many reasons to set them to be the same size). If the server is x64 (and I certainly hope it is), I would only set a pagefile on C: of 1GB for now, and leave the dump type set to minidump. This will keep your commit limit at 25GB, with 24 of those GB in RAM directly (biasing the memory manager to RAM over pagefile whenever possible). If you have a crash, you'll need to create a 25GB pagefile on C: to get a complete dump, and since that's usually not feasible on most system configurations (but only because admins don't account for pagefile size on the boot volume, they just think of Windows + Programs = x and that's all the system needs, which is OK until it breaks........).
  19. That is correct. Double-edged sword, it is - a (minor) performance benefit and the loss of crash dump creation for analysis in the event of a BSoD.
  20. Only if D: is actually on a different physical drive. Only if you don't want the welcome screen or to have multiple users logged in at once. Also note this won't work in Vista/2008, as this is now built-into winlogon itself. Re-enable it if your USB devices start behaving erratically (or not at all). Only if you don't want to host any file shares for other machines on your network. Only if you use a 3rd party utility to manage your wireless connections Only if you don't want to make any outbound connections to other machines for file or print shares. This doesn't really provide you any speed benefits, per-se, as the process is just a thread in the winlogon.exe process and only invokes on startup and when you start whacking protected files. Otherwise it's dormant, and you get maybe 12Kb back by disabling this - and you make your system more unsafe by doing so. This only disables paging the kernel executive files and dlls, not paging entirely. And if you do run your box out of RAM and need to page these to stay afloat, expect a bugcheck. If you disable Server and Workstation services, and thus can no longer host and browse SMB shares, this does you almost no good. If everyone did this, how will Microsoft know what is wrong and how to fix it, or which vendor to provide the data to? It's annoying at times, yes, but if your system apps crash enough that this becomes "annoying", perhaps you have another issue on your hands...
  21. If an installer reboots the machine before the current runonce pass is done, the installations that are left in the list will continue after the reboot. Therefore, if you can add another entry to your runonceex that reboots the box before you call the problem installer, it should work without any additional work on your part to install it after the reboot.
  22. I would suggest downloading shellexview and autoruns, disable all non-Microsoft items, reboot, and try again. The error you're getting is a simple access violation error (something, likely running inside the application or explorer.exe passed a bad pointer or returned a bad address from a call, causing the error). If that doesn't fix it, it's a problem with the app and you'll have to contact the vendor (as already noted).
  23. Some links to get you started: http://www.microsoft.com/windowsxp/64bit/default.mspx http://download.microsoft.com/download/B/8...ight_for_Me.doc http://en.wikipedia.org/wiki/Windows_XP_Pr...nal_x64_Edition The big differences are:\ 1. x86 Windows can use up to 4GB of RAM, whereas x64 can use up to 128GB of RAM in it's current iterations 2. x86 Windows can use 32 registers on an x64 CPU, whereas x64 uses all 64 CPU registers (equals faster-running apps in most scenarios) 3. x86 Windows is limited to 256MB of virtual address space in kernel nonpaged pool and ~530MB of VA in kernel paged pool (locations where the kernel and applications store information that needs to be stored in a kernel pool, like driver data) - x64 increases these pools to up to 128GB (read more about memory differences here 4. Apps running on x86 Windows are limited to 2GB or 3GB (with the /3gb boot.ini switch) of virtual address space, whereas native apps running on x64 Windows have up to 8TB of VA (32bit apps on x64 that are compiled /LARGEADDRESSAWARE can actually use up to 4GB of VA, too) There's more, but those are the basics.
  24. I would just caution everyone not to disable the task scheduler in Vista, as a WHOLE bunch of system-level services have hidden tasks there that will no longer function properly, like bluetooth, media center, defrag, hotstart and multimon config (for laptop users who use presentation monitors like projectors), reliability monitor, certain sideshow functions for those with laptops or PCs with sideshow devices, WDI, WER, and the wired/wireless info collectors, to name a few .
  25. Born and raised in NY, but I live about 1400 miles away now (about 2253km for those of you imperially challenged ).
×
×
  • Create New...