Page 4 of 4

PostPosted: 02. August 2006 00:41
by dwion
Crap! He's right folks. They don't work. I should have checked those before doing my rain dance. Nevertheless, it appears I can use XAMPP again, and like Wied says, that is all that matters to me. I'll save my OS reinstall for a boring winter day.

"services.exe" is part of the Control Center. And the CC is a third party application that we have included in the XAMPP package.

Hmmm. Well I didn't do anything out of the ordinary to Windows that should have caused such a faulter, and since the "third party" piece of yours seems to fix my real problem, then all I can say is thank goodness for your adopted apps. If I had known this would work as it did (even if not perfectly), then I wouldn't have went on for 3 pages in this forum...that's for certain! Did appreciate your help though, hope the bigger problem is eventually figured out some day.


PostPosted: 02. August 2006 17:06
by dwion
I think I have it figured out for real this time. (As it turned out, NOT YET!)


1. Create .sql dump files of your databases for safe keeping.
2. If you had been using Virtual Host Containers that worked, copy the text for those from your http-conf file and save in a text file for reuse later.
3. Completely uninstall xampp (all copies) from your machine (and any connected external drive).
4. Do a system search for "xampp" to see if any xampp-related registry files are hanging around. (I didn't have any.) If you find any, back up your registry first (do it), and then delete the files you find.
5. I found some prefetch files from the old installs at c:\WINDOWS\Prefetch. Might as well delete those too if you have them.
6. In Windows, go Start > Control Panel > Windows Firewall > Exceptions tab. Under Programs and Services find all the entries for apache, mysql, and xampp. Delete each one by clicking the name to highlight it and then clicking the Delete button. Say OK each time. Even if the paths look OK (which you can see by using the Edit button), delet all instances of these xampp-related entries.
7. Install a new version of xampp in the root drive (c:\), and do the MD5 check to make sure it's good. (I used the 7-zip executable.). Do not try and start it up!!
8.Do a system search for the file named my.ini. Mine was located at C:\WINDOWS\my.ini. Open the file and make sure the contained server path is exactly c:/xampp/mysql/bin/mysqld-nt.exe. If you're having the same problem I was, this path is most likely wrong when you open the file. Mine was pointing to a file respective to my very fist xampp installation (c:\apachefriends\xampp\...etc), which was long since gone. It's this step in particular that should go into Xammp documentation for addressing path fixes for MySQL.
9. Close everything and reboot your computer.
10. Open a command prompt, change directory to c:\xampp, and run setup_xampp.bat. You should see a normal initialization process output and be ready to go.
11. At the same command prompt, run apache_start.bat. You should see Windows Firewall asking to unblock access. Unblock, and then see a normal apache start process. Your shell will be frozen while apache is running.
12. And now for the cherry, open a new command prompt shell, change directory to c:\xampp, and run mysql_start.bat. Again you should see Windows Firewall asking to unblock the access. Unblock, and watch with happiness as mysql starts without problems:


That's it. From there it's back to configuring xampp as you normally would, setting up your databases, etc.

The key to discovery was realizing that the "my" (my.cnf) shortcut was pointing to the my.ini file. Once I realized this, found the my.ini file, and opened it, it was immediatly clear where the problem was hidden (the server path in the my.ini file).[/img]

PostPosted: 02. August 2006 17:27
by Wiedmann
The key to discovery was realizing that the "my" (my.cnf) shortcut was pointing to the my.ini file.

No. "\xampp\mysql\bin\my.cnf" is no shortcut to "\windows\my.ini". These are separate files.

Like a physician: For the moment you correct the symptoms and not the cause. ;-)

PostPosted: 04. August 2006 14:31
by dwion
Wiedmann wrote:
C:\Documents and Settings\Destry

And that's the problem. On a normal Windows this path must be "C:\xampp".
--> Because "C:\xampp" is the location of the batchfile, you have start the batchfile in this directory and so "C:\xampp" must be the working directory and not "C:\Documents and Settings\Destry".

You have start the batchfile with a doubleclick in explorer? Then you can try to start this file in the shell (cmd.exe):
Code: Select all
cd \xampp

Shizola! After all this time I finally noticed that post, which was back on page 2, though you had the file wrong (setup_xampp.bat). Nevertheless, running that didn't fix the Windows path problem, it just returned output saying "Sorry, but nothing to do!"

However, what did seem to fix it, at least as reflected in the Control Panel which is where it's been wrong all along, was to use a shell to run xampp-control.exe. This simple little move, I guess, retrained Windows to the right location.

Wiedmann wrote:You have start the batchfile with a doubleclick in explorer?

Yes, I think I did do this at one point in time. That was probably it. At any rate, I seem to be cleaning things up more and more and making good progress now. It will be the command prompt from here on out.

(How come I get the feeling you're going to tell me something else is wrong?)

PostPosted: 04. August 2006 14:57
by dwion
Wiedmann wrote:How do I check the md5 checksum? ... l#checksum

By the way, the links on that page are incorrect; they read right, but the underlying URLs are wrong.

PostPosted: 05. August 2006 03:46
by Izzy
dwion wrote:However, what did seem to fix it, at least as reflected in the Control Panel which is where it's been wrong all along, was to use a shell to run xampp-control.exe. This simple little move, I guess, retrained Windows to the right location.

So Destry, has this problem been fixed at the Widows level?

What are the results of doing the test again?

I have created an alternative to using anything to do with XAMPP to create a test situation to see if your Windows installation has indeed been fixed or not.

I have actually posted this issue in a MS MVP forum to see what the so called "experts" of the Windows OS have to input on this issue. Unfortunately the only replies up to now have been mindless and unhelpful "mine is OK, me too" types.
The thread can be seen here:

If you like you can copy and paste my original post from that forum (with edits if you prefer) to as many "expert" forums as you can find as it won't hurt and it may help find a solution both for you and for anyone else that encounters it. ;)

I reproduce, in part, that post with some editing for this forum:
Create a test.bat file that contains this:
Code: Select all

echo %cd%


Save the file to a folder on your C: drive. For this example I will save it to C:\test

Now open a command prompt:
Should return:
C:\Documents and Settings\UserName>

Now cd to the test folder on C:
cd C:\test\

Should return:

Execute the test.bat file you created and placed in there:

If it still returns:
C:\Documents and Settings\UserName>
Then the problem is not solved and may raise it's ugly head again and may not effect only XAMPP. It could effect other programs and dlls that use it.

If it returns this:
Then all is sweet and your Windows has healed. :)

You can also do the original test as outlined by Weidmann to see if you get different results this time from XAMPP.

PostPosted: 05. August 2006 13:23
by dwion
Hi Izzy, thanks for hanging in there.

I just ran your test.bat test. I put my test.bat in the C:\ root. When I start a new shell, change directory, and run the test file, I get this output...

Code: Select all
Press any key to continue...

So I guess that looks good.

Something else I notice. If I run the xampp-control.exe from the shell, then the path in the Control Panel reflects correctly, which for me is C:\xampp.

If I double-click the xampp-control.exe file (what Wied calls the Windows Explorer method), the path in the Control Panel is C:\Documents and Settings\User

It appears the key to using XAMPP (even for .exe files) is to strictly use the shell (correctly) in every possible situation.

PostPosted: 05. August 2006 13:32
by dwion
Something else:

I'm noticing that there are two instances of Apache closing every time I run xampp_stop.exe:

Apache killed...
apache.exe (nnnnn)
apache.exe (nnnnn)

Apache PID delete .... SHUTDOWN COMPLETE!

(The "nnnnn" usually changes from shutdown to shutdown.)

When I run a xampp-portcheck.exe, it shows that apache is running on both Port 80 and on Port 443. Is this normal? If not, what do I need to do?

PostPosted: 05. August 2006 13:36
by Izzy
Yes that normal, Destry.
80 = http
443= https

The nnnnn is the process ID number so you can identify a process if need be. That will change everytime you stop and start apache.

PostPosted: 05. August 2006 14:22
by dwion
Great, then it looks like I'm done here, for now, which is good because I have lots to catch up on elsewhere.

These English forums are lucky to have you, Izzy.

I hate to say it, but XAMPP's entire documentation effort, and Web site for that matter, could use an overhaul with respect to an intuitive information architecture and clearly written English content. I'm sure the nice folks at XAMPP do not agree, but they would be wrong.


PostPosted: 05. August 2006 14:35
by Izzy
Thanks Destry, we can only hope for common sense to prevail over the documentation issue. I would think there are enough English speaking XAMPP users to warrant consideration now.
Good luck. :)

PostPosted: 06. August 2006 00:16
by Wiedmann
dwion wrote:I'm noticing that there are two instances of Apache

Apache have allways two processes running on Windows.

If you have time one more question :-)

open regedit:
HKEY_CURRENT_USER\Software\Microsoft\Command Processor
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor

Is there a data field "AutoRun" and what's the value if it's exists?

PostPosted: 06. August 2006 10:56
by dwion
Wiedmann wrote:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor

The AutoRun is in this one, and there is no data value for it, the field is blank.