Vista - Diablo II takes literally 5 min to load

Vista Ultimate x64, Vista Business x64, and Vista Home x64, all have this issue:
Diablo II takes literally 5 min to load. We thought that for certain that the game just wasn't going to work under Vista x64, and I was ready to give up on it... but then one of the machines just popped to life.

Since then, I've been running it by starting it... and then literally go for a soda or a beer in order to pass the 5 mins it takes for anything to happen.

I can see in the task manager that game.exe*32 is running... at 0% cpu... for a long, long time. No activity that is measurable by task manager. Then, eventually, the screen goes black and the intro begins running.

Once that happens, Diablo II appears to be fine (there are some issues with it failing to fully initialize or restore the graphics pallete when I alt-tab away, but that seems to self-fix when I alt-tab a second time).

Has anyone else seen this - or know of a solution for it?

I mean, 5 mins real time is a LOOOOOOOOOOOOOOONG LONG time when you're wondering why nothing is happening in front of your PC!

Try defraging your computer also try running in compatability mode for xp, check to see if you have the latest graphics card update.

This problem occurs on all 3 machines that are running Vista (2 are running x64, one is x32). Two use Intel Dual or Quad 2 Core CPUs. One uses an AMD dual core. All have 2 or 4GB of ram, and all have what would be insanely over the top video cards relative to Diablo2.

If this was one machine, I'd question things like individual components in the PC. But three different machines, all running very different hardware, with the only real common denominator being Vista (even x64 vs. 32 bit varies)...

Nope, this is a Windows Vista compatibility issue.

The biggest oddity to me is that I can't seem to find anyone else experiencing this issue (yet it affects all 3 of my Vista based PCs).

...and I have tried various compatibility settings for both the launcher.exe and the game.exe - none have any effect that I can discern.

Have you tried running the game with admin rights.

I have disabled UAC on all machines (so in every instance, the logged on user is an admin, and UAC never tries to interfere - just like an admin account under XP would be).

Good thought though! I wish it were that simple.

The one other thing that is in common on all machines, besides being Vista, is that they're all multi-core CPUs - an Intel quad, and AMD dual, and an Intel dual. Anyone else having trouble with Diablo 2 under multi core systems?

Oh - and I want to stress: the CPU is at 0%, and the hard drive is not lighting up (zero activity)!

So - whatever it is doing, it is doing barely - it is not waiting on CPU or harddrive for certain.

That doesn't really answer mansrm81's question. Just because you're logged on as admin, and just because you've disabled the User Account Control doesn't mean that all your programs will run as admin... at least that's my understanding? Could be wrong, I'll go consult the manual, but even though I log in as admin, I still have to set certain games to run as admin.

I'll check on it though and post back.

Fumz,

When UAC is disabled, then starting a new process takes the user's security token, which, if they are logged in using an account which is a member of the Administrators built-in group, means that every process launched by that user has administrative privileges. This is exactly how the original security model developed for NT, and essentially used unchanged in 2000 and XP, was designed.

However, Microsoft knew as well as anyone that this was dangerous, because automatically giving every process the user spawns full control over the local machine meant every process was libel to do any sorts of nasty things without the security system helping limit their damages. It also opened the door for malicious software to find a loophole that allowed it to start up (even user-foolishness), and once started, could potentially have Administrator privileges simply because the currently logged on user had them. And of course, entirely too many things under NT/2000/XP required Administrator privileges as far as users were concerned, so the habit became that everyone should just have admin privileges so that it was not a total PIA everytime you wanted to install software or insert a thumb drive.

With UAC, Microsoft created a way to give each process spawned by anyone - standard user or an admin account, only standard user security by default. Then, if the process asked for more, an explicit dialog would be shown to allow the user to supply additional credentials and enable that application to obtain the needed security token(s).

By disabling UAC, and having all workstations log in as admin accounts, I have effectively returned to the exact same model that NT/2000/XP uses: all process inherit the currently logged in user's security credentials, meaning in this case, all processes are running as admin.

You're right. I thought there was a difference because I have to elevate for an admin cmd prompt, but forgot the default admin wasn't really admin.

Anyway, is it still possible that somehow (don't ask me how) UAC being disabled is the cause? As far as I can see, a disabled UAC is the only common denominator across all 3 machines, right?

I'll try enabling UAC when I get home, see if it makes a difference.

You never know.

Alternately, I could try running it in a VM.

Common Denomenators:
+ Vista
+ Multiple Core CPU
+ Lots of Ram (2-4GB)
+ Reasonably High End Machines (by current standards)
+ Configuration of UAC

Not in Common:
+ Make of Video Card
+ 32 vs. 64 bit
+ Make of CPU
+ Number of CPU cores

yeah, this is a weird one that affects all 3 of my Vista machines, but nobody out there seems to have this same pattern!