Faulting: svchost.exe, msi.dll

So I started up my laptop today to do a little gaming, and got an error message while I was still sitting at the login prompt that read:
svchost.exe -- application error the instruction at "[some address]” reference memory at “0×00000000″. the memory could not be ‘read’Faulting application svchost.exe, version 5.1.2600.2180, faulting module msi.dll, version 3.1.4000.2435, fault address [some address]
I clicked the okay button on the error message, and it went away, but then whenever I would try to start a program (any program) the process would appear, but the window for the program never would. Hard rebooting didn’t fix the problem, and I was getting exteremly frustrated after multiple reboots. I finally went to another computer and did a search, and after a lot of reading, ended up at the following address:

http://swigartconsulting.blogs.com/tech_blender/2006/07/windows_update_.html

It described my problem exactly, and chased my nightmares away. If you’ve found my page because you’re having the same problem, follow the link above and read the whole blog post. It resolved my problem immediately, and saved me a lot of time repairing/reinstalling windows.

Published in: on 15 February 2007 at 2:52 pm Comments (0)

IE7 = Garbage

IE7. Annoys. Me.

I play an MMORPG on an account that I share with my Sister-in-law and her husband. I’ve scripted a webpage that keeps track of who’s logged in so we don’t log in on top of each other and boot each other off. I’ve written this script as one page that stores data in a database and restrieves it. Because of how the data is transmitted to the database from the web page (via the HTML POST method), under normal conditions refreshing the page by hitting f5 or clicking the refresh button will warn you that this will repeat any action you just took (sign you in again, or attempt to sign you out again, etc.). If the user clicks “OK” and resubmits the data, it can cause problems with who appears to be playing.

To get around this, I use Sessions. Basically, it puts a cookie on the user’s computer that stores the POST information, clears the POST data, and the script uses the session information to interact with the database. I used the following code, though I don’t remember where I found it, to use sessions:

session_set_cookie_params(1);
session_start();
if(!empty($_POST)) {
$_SESSION+=$_POST;
header(”Location: ” . $_SERVER['SCRIPT_NAME']);
session_write_close();
exit();
}

One of the features of setting a Session cookie is the abilit to specify when the cookie will expire. If you don’t specify an amount of time for the cookie’s lifetime, it expires when the browser is closed. As long as the cookie has not expired, trying to sign in or out will just repeat the last action you did, whose information is stored in the cookie.

I have set a lifetime for my session cookies of 1 second. (That’s what the session_set_cookie_params(1); line in the above code does) The life time is defined in seconds, it’s the only unit you can use, so when you specify the lifetime, you just use a number (”1″ in my case). IE6, FF, Opera, Safari, and every other conceivable web browser handle this correctly, and I don’t have problems.

My in-laws just upgraded to IE7, and the page stopped working for them. They’d try to sign out, and it would sign them in again, or if they’d just signed out successfully (say my sister-in-law had been playing and now the husband wanted to), no one would be able to sign in again. So I started testing this, and it appears that IE7 interprets the lifetime part of the cookie as being minutes instead of seconds. After a lot of putzing around last night, I finally figured out how to manually expire the cookie once the page had finished loading, using the code posted below (which I pulled from the page for session_destroy at php.net) at the end of the script, and it’s working again now. The first line clears the $_SESSION autoglobal. The if statement looks to see if there’s still an unexpired cookie with the appropriate session name, and sets its expiration time 700 minutes in the past (a little overkill, perhaps). The last line destroys the session information.

$_SESSION = array();
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(),”",time()-42000,’/');
}
session_destroy();

BUT WHY, OH WHY can Microsoft not write their software to conform to standard specifications? Why? I really, really, dislike IE7 right now.

Published in: on 8 February 2007 at 10:34 am Comments (0)

When it rains in the server room…

We had some excitement here in at work last week. On Thursday I was sitting in my office trying to set up a server when suddenly the server stopped responding. I was a bit worried, because I hadn’t done anything that could have caused it to hang up, so I tried to reach it another way and realized that I’d lost my network connectivity altogether. Right about then I got a knock on my office door and one of my employees said, “Um… there’s water pouring out of the server room…”

What?!

Sure enough, when I checked, there was about a quarter of an inch of water on the floor outside the server room and it was quickly spreading. All of our network equipment is in that room, so I quickly opened the door and found that it was raining
(rain-forest raining, you know where it’s so humid the water just seems to be forming into droplets out of the air around you) down directly on the rack that ouses our equipment. I ran in there, jumping as I grabbed the power cords to ensure that I didn’t electrocute myself, getting drenched the whole time, and managed to get the power cut off to all of our equipment, and then had to go kick about a hundred students out of the lab, telling them that they wouldn’t be able to print, access email, or really anything else. Some had no way of saving what they were working on, so I started scrounging up floppy disks to help them out.

Before we found out what had caused the indoor monsoon, the networking guys got here and started pulling out the equipment, and water poured out of every single thing they took off the rack. We pulled them all into my office and opened them up to let them dry out, and started trying to figure out what was going on.

Turns out a custodian had broken a pipe directly over our server room while cleaning, and instead of telling someone about it, he decided to hold on to it for 10 minutes and see if he could somehow stop the water with his bare hands (Typing that makes me think of that song, “Jackie-chan-jackie-chan-jackie-jackie-chan-chan….” for some reason). That ten minutes allowed the water to pool in the ceiling above our server room and start leaking down through it. Had the dude told someone immediately, we’d probably have been able to cover our equipment and get it shut down and only been out of commission for a couple of hours.

As it was, the lab was out of commission for the rest of the day about 8 hours) waiting for the drenched equipment to dry out enough for us to test it. Once that had happened we started firing things up and out of 4 switches ($1000-$1500 each), 1 UPS ($3000) 1 router ($2500) and 1 server ($2500), we only lost two switches. Everything else fired up again. We decided to let the room air out and dehumidify over night, and got everything put back in and all 120 computers reconnected by about noon the next day.

This was in one of the most used computer labs on campus, and my staff were spending all their time turning people away and explaining why the computers didn’t work. It was quite the ordeal, though I can *almost* laugh about it now.

Published in: on 5 February 2007 at 8:58 am Comments (0)