The HTTP Status Code “404” means the requested resource was simply “not found”. Unfortunately, this gets abused. There are several programs including IIS which will issue a “404” status when the problem has nothing to do with a missing resource. Use the quick links below to browse different reasons why this might be occurring.
The Path Is Incorrect
One overlooked option is simply using the wrong path. Many times people will forget a part of the URL, such as the cgi-bin, and use http://www.Example.com/Cart32.exe instead of http://www.Example.com/cgi-bin/Cart32.exe. Make sure your IIS entry points to the proper directory on your server, and verify that your URL in your browser’s address bar is pointing to the correct location (and spelled correctly).
Web Service Extensions Are Not Set Up
If your server is running Windows Server 2003 or newer, you have to set up Web Service Extensions for the executable files. Please refer to this article for instructions on how to set up web service extensions.
Data Execution Prevention Is Mis-configured
If your server is running Windows Server 2003 or newer, you may have to configure your Data Execution Prevention to allow Cart32 to run. Honestly, a mis-configured DEP typically results in an error called “Application Misbehaved By Not Returning A Complete Set Of Headers” (article on that found here). However, it can also cause a 404 status in some situations. Please refer to this article for instructions on how to set up DEP for Cart32.
URLScan Is Running On The Server
URLScan is a tool for securing IIS beyond it’s original design. URLScan is integrated in the IISLockDown program. If you are using URLScan you have to make some modifications or you will get an error (normally a 404 status code) when you try to use Cart32. To allow Cart32 to run we have to add an allowance to the URLScan configuration. Use the following steps to modify URLScan to allow Cart32 to work:
- Open your URLScan ini file with Notepad. This is usually located in # %systemroot%\system32\inetsrv\urlscan. (Start –> Run –> type “%systemroot%\system32\inetsrv\urlscan” (no quotes) and click OK.
- Once you’ve opened the ini file, find the line that looks like one of these two options:
Very Important: The steps we just did will determine whether or not we use the [AllowExtensions] or the [DenyExtensions] list further in the ini file. It is extremely important you understand the difference this setting makes, otherwise your ini changes might prove useless.
- [AllowExtensions]: When UseAllowExtensions=1 is set URLScan will act in a very strict mode. It will require all file extensions that the web server wants to provide to be listed in the ini. For example, if you wanted to allow IIS to server .zip files you would have to make sure the extension “.zip” (no quotes) was listed in the [AllowExtensions] section of the ini.
- [DenyExtensions]: When UseAllowExtensions=0 is set URLScan will operate more loosely. It will allow any file extension to be served except those listed in the [DenyExtensions] section of the ini. This is the default configuration for URLScan
If you have UseAllowExtensions=1 set then all you have to do is add the .exe extension to the [AllowExtensions] section like so:
If you have UseAllowExtensions=0 set then you simply have to comment out the .exe extension from the [DenyExtensions] section with a semi-colon like so:
(Note: Don’t forget to save your ini after you make changes and restart IIS)