cluberti

OK, you created a dump - can you put the .dmp file (compressed, of course) somewhere where it can be downloaded and analyzed?

Wow, that was ugly - next time just attach the .dmp files . Anyway, the error is c0000005, which means "access denied". So bioshock.exe was doing a compare of some register math and 0, and what it's doing makes me think that the memory that AFAB564 points to is probably invalid: cmp dword ptr [ecx+eax*8+0x1c],0x0 ds:0023:0afab564=????????Which really means: cmp == compare operation dword ptr == the address to compare will be a dword-aligned pointer [ecx (09c70000) + eax*8 (002676a9) + 0x1c] == the address of the pointer (which is 0afab564) ,0x0 == compare the data the memory address points to with 0 However, as you can see above, 0afab5640 points to a memory address that contains no data (=????????) which causes the access violation. So, I'd contact the folks at 2KGames that make Bioshock and ask them what happened, because they are expecting the math above to return a pointer that == 0x0, not ???????? .

I've seen HP drivers do this before - check the event log (app and system) for events from the source "Print". See if it's reinstalling the printer driver every time you try to do this (if so, it will be logged).

Assuming you're talking about remote-controlling another users' machine, you can consider using Remote Assistance for this (uses RDP, but connects the remote user to the console session that the local user is seeing). Otherwise, VNC is another good choice.

Applications don't know anything about RAM, only virtual address space. They're limited to 4GB of VA, of which 1 or 2GB (depending on if /3GB is used in boot.ini) is used by the kernel, and 2 or 3GB is available to the application. The NT memory manager determines whether those VA pages are mapped into physical RAM or into the pagefile.I will agree, however, that systems with 2 or 3GB of RAM can still benefit from 64bit Windows, especially when running native 64bit apps (being able to access 64 registers on the CPU instead of 32 can bring great speed increases). I would suggest anyone with 2 or more GB of RAM to consider x64 before making a final decision - if all of your apps will work (or can be made to work), choosing x64 over x86 makes sense. If you have any app compat issues, of course, x86 is still a safe bet.

If you're using SP1, Vista UI was changed to show the installed memory, rather than available memory. msinfo32 still shows the difference, as previous.

Nice to see Mark getting on the bandwagon. Documented/dealt with here on MSFN over a year ago .

If your tool is 64bit it'll use the 64bit odbc components, and if it's 32bit it'll use the 32bit components. As you can see, there are far more 32bit than 64bit components.

This sort of discussion is not allowed, and comes under rule #1 (moving files from one SKU with a feature to another without). You have been warned, thread closed.

With vlite you create an install image. What I wanted to know was a method NOT requiring a reinstall of the entire OS. Short of going in and hacking away at it (and praying for the best), no there's no way of shrinking this folder easily (or maybe at all). This was discussed here awhile back as well, with some success by some people and epic failure by others, IIRC. You can probably find that thread if you do a quick search and want to read up on it.

It's not possible with the inbox tools in the service manager, but 3rd party software (including Microsoft's System Center Operations Manager) can do such a thing. However, you could write a script that runs from task manager on set intervals to check service status and do something based on the check result, and that would probably work just fine.

It's failing to create the mmc instance being loaded via reflection, and this could be anything from security issues to a task in the scheduler causing the issue (although that's highly unlikely, it's possible). I would strongly suggest opening the event viewer and looking in the System and/or Application logs to see if anything further is actually being logged regarding this error (there should be).

If you want to be sure, attach adplus to explorer and get a crash dump of the application.

The Unattended Guide has info on how to make registry changes in your runonce.

Look into the Microsoft Deployment Toolkit and Windows Deployment Services (ships with Windows Server 2003 SP2 and Server 2008). These provide the easiest way to deploy XP and Vista. Also, if you can get yourself a copy of the Vista Resource Kit (2nd Edition) it will go into far more detail on MDT than you will find most places. However, good video documentation on how to set up a base build using these tools is here.

Honestly, I think this is the best way to deploy Acrobat Reader 9 silently, and without unnecessary components.

Always watch out for those, which is why I suggested removing them .

I believe that x64 SP2 already contains MDAC 2.8 SP2. You can run odbcad32.exe from a command prompt to see the x64 components (open a 32bit command prompt and run the command there to see the 32bit components).

This is not a memory error, but rather a desktop heap resource issue. How many apps/windows/etc do you have open, and/or how many sheets does this workbook have? Also, can you reproduce this with just Excel and this workbook open?

Not a problem - if you've got a Premier agreement with SA, you likely have access to the Microsoft DART toolkit, which includes the ERD boot CD (it gives you access to the event logs, etc, offline - might be useful in troubleshooting). Honestly though, it sounds like there's a driver in the 2000 install that Windows is either not upgrading that is causing the issue, or it's trying to upgrade it and failing (both would cause a BSOD if the driver is a kernel driver, which it seems to be). Your best bet might be to use the USMT to migrate settings and do a clean install as per your second option.

Before you start the upgrade (and this assumes you have a null-modem cable and a second machine to do the monitoring), you can configre the 2000 box to be debugged - if/when it bugchecks, the debugger on the second machine attached via the null-modem will break in on KeBugCheck so you can at least see what's going on. And your upgrade should technically work (I don't think OEM to VL is "supported", however it should "work").

It's worked well for Apple. Worth trying.

I'm unclear as to the problem - you installed DFS on the WDS server and at least one other server, and you've put the images on the DFS target. When a client connects to the WDS server and requests an image, and is told to get it from the target, it should grab it from the target from either the WDS server or the other server(s), depending on which is closer or however else you've set up your DFS. What exactly is the question?

http://technet.microsoft.com/en-us/library/cc771324.aspx I think that is exactly what you want to do, no?

Ask Google how well they're doing at migrating Microsoft contract shops over to other OSes and suites (hint - it's not working).