I am running a Web app on the Abyss Web server on Windows 2008 Server Standard. It has worked until the latest deployment with 2014x2.1 and a new version of Web Custom Controls (Taylor Design). This version gets a 500 error on launch after the configured 30 second timeout. It works fine in debug on my MacBook.
The Abyss logs do not show any errors. I have opened a support ticket with Abyss in regard to how to debug but I have not heard back yet.
I have never used remote debug. Would it work here? It appears that nothing ever runs. I get no “launching” page and on Safari the address field color bar moves a sort distance and freezes then in 30 seconds the 500 error appears. It appears the EXE never runs.
I can put the old version back and it works fine (I saved the deployment copy). I would have to do a little work to return to the old version and recompile it from a back up copy.
Any debugging thoughts would be appreciated.
Does an empty Xojo project from 2914r2.1 work?
Greg,
I have another small project compiled with 2.1 that did NOT have any of Daniels controls in it and that works fine. I added his controls and it still works fine. I will go back and add the last control I added in the other app that gets the 500 error to see if that is a problem.
After some confusion I found the log file and it has an 500 412 error. The 412 says:
Precondition Failed
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
So any thoughts about the 412? Since I don’t see the “Launching” page is this not getting past being launched by the Perl script? Other XOJO sites on the same server with the same path to Perl work just fine.
Thanks, Mark
Well, we don’t generate a 412 error internally, so it’s not coming from us.
I figured it was not a XOJO error since I do not even see the launching screen. I just cannot figure out how to debug it. I suppose I could play with the Perl script that launches the EXE and log some steps to see where it stops … but I will have to learn a little Perl.
I replaced the Perl launch script with the one that works from a previous version but I have the same error.
Are there any tricks like run the EXE from a command window with some special switches?
STRANGE … VERY VERY STRANGE … possible corrupt or bad DLL or other support file
OK ---- If I try to run the EXE via the Perl script from the command line for the old version it shows this (below) after a few seconds (and more non printable characters) then Perl quits but it appears from looking at Task Manager that the EXE is running. It even remains running AFTER Perl ends (verified by the Task Manager).
C:\\Abyss Web Server\\htdocs\\HCFS>perl homecarefamilyservices.cgi
Status: 200
Content-Type: text/html
Date: Wed, 01 Oct 2014 19:05:09 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
Content-Length: 790
<a block of non printable characters follow>
If I try the same trick with the NEW version. It waits about 45 seconds and Perl just ends with no output. Looking at Task Manager the EXE never appears.
So it seems that Perl cannot launch the EXE in the second directory.
BUT — Just for fun I copied ONLY the EXE from the newly compiled version and put it in to the directory for the old version AND IT WORKED! That would indicate that maybe one of the support files (DLL’s or others) are bad or maybe a permission problem. I looked at most of the security info (right click and properties in Windows) but everything looks the same.
I suppose this could all be a problem with the Abyss configuration for the second Website but I don’t think so. I just copied all of the files from the new working version in the old directory to the previously non working directory and that now also works.
I will spend some time and see if I can track down the problem file. If it looks like a XOJO problem I will let you know.
Oh I just love being out on the frontier … it is easy to tell if you are a pioneer … you always have lots of arrows in your back.
If the problem were with Xojo, we would be getting a lot more bug reports. Try copying the WHOLE app, dlls and all into the directory that works and see what happens.
After some tinkering I think maybe it was more than one thing but it was not really an XOJO bug. When I deployed a separate host in Abyss for testing I did NOT change change the app identifier. I think also that I did a few other “boo boos” in the Abyss config and maybe the browser cache was giving me some trouble.