Ever since Microsoft began offering Virtual PC for free to download, a lot of users have been installing it to test out the usefulness of virtual machines. A couple laptop users complained that their machines would blue screen while starting up Windows with the wired network cable plugged in, although Windows would start up fine with the cable unplugged (which could then be plugged back in after login). I couldn’t figure it out but did narrow it down to Virtual PC 2004 being installed. I finally had the chance to work on one of these laptops for longer than five minutes and began my search on Google for the answer since I sure couldn’t do it myself.
All of my searches for a combination of the words “virtual pc ndis.sys blue screen driver_irql_not_less_or_equal” came up with irrelevant results. The only page that came close was this newsgroup post that suggested that there was a conflict between Virtual PC and the VPN client (Nortel Contivity VPN) installed on the laptop. So I went off searching for more details about the conflict and found this page that suggested uninstalling both Virtual PC and the VPN client, then reinstalling Virtual PC first before reinstalling the VPN client.
Well, first I uninstalled the VPN client and tested to see if the problem really went away. It did. I noticed that version 5.x of the client was installed so I tried installing 6.x. The problem came back. Uninstalled VPN, uninstalled Virtual PC, rebooted, reinstalled Virtual PC, rebooted, reinstalled VPN, rebooted, blue screen.
I decided to see why these two software would conflict. I went to Control Panel, Network Connections, opened the properties of the wired connection and examined the list of services and protocols enabled for the connection. The ones of note were the network filter services: Virtual Machine Network Services (from Virtual PC), Eacfilt (from VPN client), and Odyssey Network Services (from Funk Odyssey wireless client software). I unchecked the Virtual PC service from the adapter, rebooted, and everything was fine except that the adapter was no longer available for use within Virtual PC.
Back to the services list, I couldn’t uncheck the VPN service since the user would need it on this adapter but I wondered why the Odyssey service was enabled on the wired adapter. I rechecked the Virtual PC service and unchecked the wireless service. Rebooted and everything was fine! Checked to make sure Odyssey was working with the wireless adapter, checked to make sure Virtual PC worked with both adapters, and checked to make sure VPN worked with both adapters. Success!
Summary: If you’re getting the same type of blue screen from NDIS.SYS that I observed, check your list of services enabled for the wired adapter and disable any unnecessary services. Good luck!
January 5th, 2007 at 03:04pm
Explorer.exe started using 100% CPU about 5 minutes after login. The user had run Spybot, Ad-Aware, and Trend Micro scans and nothing showed up. I took a look at the startup items with msconfig and couldn’t find anything myself. I first ran Process Explorer and couldn’t find anything obvious that was hooked into explorer.exe that would cause the problem (moral of the story: I didn’t know how to use Process Explorer). I ran TCPView and noticed that at login, explorer.exe was trying to connect to an intercage.com IP address (which didn’t respond to pings). As soon as the TCP connection died, explorer.exe CPU usage jumped to 100%. If I end-tasked explorer.exe and re-ran it, it wouldn’t try to make the connection again and it would never use 100% CPU again. If I booted up without a network connection, everything was okay. Once I connected though, explorer.exe would try to make the TCP connection with the mysterious IP again.
After tons and tons of troubleshooting (Filemon, Regmon, SFC, etc.) and searching for solutions (”explorer.exe 100% cpu”, “explorer.exe 99% cpu”, “explorer.exe 90% cpu”, “explorer.exe syn_start”, “explorer.exe close_wait”, “OMG!”), I took a deeper look at Process Explorer’s features. I thought all I could do with the program was look at (and close) the open handles of a process with the main window but if you right-click on a process and go to Process Properties, there’s also a useful Threads tab. In this tab, I was able to find a thread which was created by (right?) webcpl.dll and was using 100% CPU. I was able to kill the thread and voila! Explorer.exe was acting normal again. I found the culprit in %windir%\system32. I opened the file up in Notepad and I found a reference to the IP that TCPView showed. I deleted the file, found one reference in the registry to the DLL, and deleted that (probably should’ve unregistered it instead?).
Now everything is happy. Explorer.exe is no longer trying to connect to the IP and it doesn’t use up the CPU. I searched for more information about the DLL but all I could find was a forum thread about Panda Antivirus detecting it as the Downloader.GRG trojan and not being able to delete it. Panda’s site didn’t have much information about it though. Oh well.
January 12th, 2006 at 04:32pm
While visiting a secure trusted site in IE, you may encounter links to files which cannot be opened or saved. You receive the message: Some files can harm your computer. If the file information below looks suspicious, or you do not fully trust the source, do not open or save this file. You search Microsoft.com and come up with KB840386: Cannot open an Excel 2003 workbook by using Internet Explorer 6.0 but it’s no help. The page says there’s a hotfix but you need to have a service agreement with Microsoft to download it.
The solution? I found this page (brianmadden.com) which contained a solution posted by an anonymous user. Go to Tools > Internet Options > Advanced tab > Uncheck “Do not save encrypted pages to disk.” What’s really happening is that the file is being served over a secure connection so with that option enabled, IE is not allowed to save it to the disk. Therefore you can’t download the file or even open it since it cannot save it temporarily to disk. This option is disabled by default.
Unfortunately, the page that contains the solution isn’t found when searching for the exact error message. Instead, I found it by accidentally searching for “some files may harm your computer.”
December 12th, 2005 at 05:28pm
Boy did I have a hard time getting PHP and Apache to work under Cygwin. I had to set the environment up for a class project so first I did what any reasonably lazy person would do–check for a Cygwin package. I only saw the Apache package but I needed PHP too so I decided to hold off on installing it. So next I did what any reasonably lazy person would do next–Google for a page posted by someone who did the work already so I wouldn’t have to.
After browsing through numerous pages of Google results, I couldn’t come up with anything for the search terms ‘cygwin apache php’. Of course now that I just re-searched for those terms, the page I ended up with at the end of my journey is the fifth result. More on that later.
Instead, this site (Index of /support/cygwin-packages/apache-modules/mod_php4) caught my eye. It was the eighth result and I thought to myself, “OMG, there’s a package available!” So off I go to download and install the package. I installed the Apache and Apache-PHP packages. Now I might not be the most experienced Cygwin user so maybe I didn’t install the package correctly because it didn’t check for any of the dependencies. After looking at the setup.hint file, I installed the required packages and I thought I was set (cygwin apache libgdbm openssl bzip2 zlib gettext libxml2 postgresql libbz2_0 libbz2_1 rebase).
To start Apache, I ran ‘/usr/sbin/apachectl start’ and I saw that it started the http daemon. Woohoo! I made a test PHP file in /var/www/htdocs but it wasn’t being parsed. What gives? I looked at /etc/apache/httpd.conf for the appropriate PHP module lines but they weren’t there. Then I realized that installing both the Apache and Apache-PHP packages at the same time must not have been a good idea. I reinstalled the Apache-PHP package and it made the appropriate changes to the httpd.conf file. Now to restart the daemon…
# /usr/sbin/apachectl start
Syntax error on line 236 of /etc/apache/httpd.conf:
Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 998
/usr/sbin/apachectl start: httpd could not be started
Hrm? Being the reasonably lazy guy that I am, I set off to Google in search for an answer. The results were mostly mailing list archives for people getting the error message without a resolution. Some people suggested rebasing the DLL so I tried that. Nope, same error. Other people suggested running ‘cygcheck libphp4.dll’ to check for any dependency problems. I did that and received some ‘could not find something.dll’ errors. So I tried to look for them and also for any packages which might have them. I couldn’t find cyghttpd.dll or cygcrypto.dll and I googled for the packages containing them but it seems that I already had them (Apache and OpenSSL). So I just made copies of libhttpd.dll and cygcrypto-0.9.7.dll to the respective missing files and hoped that the problem would be solved. I ran cygcheck and everything was okay so I tried to start up http daemon again. Same error.
I decided to rethink the strategy to take. How about compiling PHP myself? So I downloaded the PHP source files and looked at the INSTALL file. I decided to just try ‘./configure’ without any parameters first because I didn’t want to deal with them (read: lazy). It said it couldn’t find lex. D’oh, another package to install (flex). Then I ran configure again and it started doing it’s thing.
While configure was running, I decided to go back to my Google search results and see if I could find any useful information. Then I stumbled upon this page (Cygwin/apache/php - discypus). The Google page summary was in Japanese and what’s a discypus? Who knows, let’s click on the link! Even though I’ve only had four quarters of Japanese and couldn’t read any of the kanji, I understood “Apache 1.3.29-2 + PHP 4.3.8 (2004-07-26)”. I scrolled down a little more and, “OMG! PHP compiling instructions for Cygwin!” Since this information was on a Japanese site, I cancelled my configure immediately. I followed the instructions to a T and ended up with a working Apache with PHP (minus the MySQL which I didn’t really need anyway). The Discypus wiki is a goldmine of Cygwin information (and more!). Moral of the story? Trust any Japanese sites you visit.
Here are the instructions with some translatations. All credit goes to Discypus.
1. Required Cygwin packages (in addition to the ones mentioned above):
$ grep -A20 '@ apache' setup.ini | grep require
requires: cygwin crypt libgdbm4
$ cygcheck -cd cygwin apache crypt libgdbm4
Cygwin Package Information
Package Version
apache 1.3.29-2
crypt 1.1-1
cygwin 1.5.10-3
libgdbm4 1.8.3-7
2. Extract the PHP source files:
$ cd /usr/local/src/php
$ tar jxvf php-4.3.8.tar.bz2
php-4.3.8/
php-4.3.8/ext/
:
php-4.3.8/README.UNIX-BUILD-SYSTEM
php-4.3.8/php4.spec.in
3. Run configure:
$ cd php-4.3.8
$ ./configure --with-apxs=/usr/sbin/apxs --without-mysql --enable-mbstring
creating cache ./config.cache
checking host system type... i686-pc-cygwin
:
creating main/internal_functions_cli.c
+--------------------------------------------------------------------+
| License: |
| This software is subject to the PHP License, available in this |
| distribution in the file LICENSE. By continuing this installation |
| process, you are bound by the terms of this license agreement. |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point. |
+--------------------------------------------------------------------+
| *** NOTE *** |
| The default for register_globals is now OFF! |
| |
| If your application relies on register_globals being ON, you |
| should explicitly set it to on in your php.ini file. |
| Note that you are strongly encouraged to read |
| http://www.php.net/manual/en/security.registerglobals.php |
| about the implications of having register_globals set to on, and |
| avoid using it if possible. |
+--------------------------------------------------------------------+
Thank you for using PHP.
4. Modifying the Makefile:
$ sed -i.org 's/libphp4.so/libphp4.dll/g' Makefile
$ diff Makefile.org Makefile
:
5. Run make:
$ make
:
Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
6. Compile the PHP libraries:
$ cd libs
$ ls
libphp4.a libphp4.la
$ gcc -shared -o libphp4.dll -Wl,--out-implib=libphp4.dll.a
-Wl,--export-all-symbols
-Wl,--whole-archive libphp4.a /bin/cyghttpd.dll
-Wl,--no-whole-archive -lcrypt -lresolv
Creating library file: libphp4.dll.a
Info: resolving _ap_user_id by linking to __imp__ap_user_id (auto-import)
Info: resolving _ap_group_id by linking to __imp__ap_group_id (auto-import)
Info: resolving _ap_user_name by linking to __imp__ap_user_name (auto-import)
Info: resolving _ap_max_requests_per_child by linking to __imp__ap_max_requests_
per_child (auto-import)
Info: resolving _ap_server_root by linking to __imp__ap_server_root (auto-import
)
Info: resolving _top_module by linking to __imp__top_module (auto-import)
$ ls
libphp4.a libphp4.dll libphp4.dll.a libphp4.la
7. Run make install:
$ cd ..
$ make install
Installing PHP SAPI module: apache
[activating module `php4' in /etc/apache/httpd.conf]
cp libs/libphp4.dll /usr/lib/apache/libphp4.dll
chmod 755 /usr/lib/apache/libphp4.dll
cp /etc/apache/httpd.conf /etc/apache/httpd.conf.bak
cp /etc/apache/httpd.conf.new /etc/apache/httpd.conf
rm /etc/apache/httpd.conf.new
Installing PHP CLI binary: /usr/local/bin/
Installing PHP CLI man page: /usr/local/man/man1/
Installing PEAR environment: /usr/local/lib/php/
[PEAR] Archive_Tar - installed: 1.1
[PEAR] Console_Getopt - installed: 1.2
[PEAR] PEAR - installed: 1.3.2
Wrote PEAR system config file at: /usr/local/etc/pear.conf
You may want to add: /usr/local/lib/php to your php.ini include_path
[PEAR] DB - installed: 1.6.2
[PEAR] HTTP - installed: 1.2.2
[PEAR] Mail - installed: 1.1.3
[PEAR] Net_SMTP - installed: 1.2.3
[PEAR] Net_Socket - installed: 1.0.1
[PEAR] XML_Parser - installed: 1.0.1
[PEAR] XML_RPC - installed: 1.1.0
Installing build environment: /usr/local/lib/php/build/
Installing header files: /usr/local/include/php/
Installing helper programs: /usr/local/bin/
program: phpize
program: php-config
program: phpextdist
8. Make sure the following two lines were added to /etc/apache/httpd.conf (if not, add them):
LoadModule php4_module lib/apache/libphp4.dll
AddModule mod_php4.c
9. Add the following two lines to the same file in the appropriate section (I just added the first line to the end of the file):
#
# Document types.
#
:
# for PHP 4.x
#
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
10. Check the contents of httpd.conf:
$ /usr/sbin/apachectl configtest
Syntax OK
11. Start the http daemon
12. Create a test file /var/www/htdocs/phpinfo.php:
<?php phpinfo(); ?>
13. Test the file at http://localhost/phpinfo.php
May 31st, 2005 at 10:15pm