LV2010 WebService Crash on WinXP

[soren_jensen]

How to crash the LV2010 XP webservice:

Setup to "hello world" webservice called for example 'cjc', create a URL binding called for instance 'getdata',

this binding should bind to a VI called getdata.vi.

In other words a web-service that should respond to the URL:

http://127.0.0.1/cjc/getdata?test

In Internet explorer, call the webservice by typing in the URL:

http://127.0.0.1/cjc/getdata.vi?test

which of course should have been:

http://127.0.0.1/cjc/getdata?test

This will crash the webservice, displaying the dialog attached. Next time you try to deploy the same webservice, a username/password dialog apears. Restarting the NI Application web srever may work (Run:services.msc). But at least once I have seen that not work, whereafter I had to run misblast.exe and spend most of my morning reinstalling LabVIEW in order to get back on track.

P.S. if you type "http://127.0.0.1/cjc/getdata1?test" you get the expected 404 Not found err.

[MarkBlack]

Hi Soren,

This is an interesting crash that has not yet been documented.  If possible I would like you to post your example project and VI so I can attempt to reproduce the crash.  I have a couple of questions?

1. What port is the Application Web Server running on?  It looks like you set it up to run on port 80, but if you have not explicitly done this you will always receive a 404 error when using the http://127.0.0.1/cjc/getdata?test URI.
2. I want to make sure I understand this correctly.  Accessing http://127.0.0.1/cjc/getdata.vi?test causes a crash.   Accessing http://127.0.0.1/cjc/getdata?test does not cause a crash (404 instead).

When you receive this login dialog at deploy it is because LabVIEW cannot access the Application Web Server.  We are working to improve this behavior so it is clearer to users what the issue is.  In your case, the reason you saw the dialog is because the Application web server had crashed.  Restarting it from services.msc is the next logical step.  If this does not work (as it did in your case), please reboot the system.  If the error is still occurring after a reboot, it is possible this is caused by a web service that has already been deployed.  If this case please do the following.

• Follow the instructions in this KB (http://digital.ni.com/public.nsf/allkb/05AD2189D1E0D8A28625776800711DE0?OpenDocument) to enable web service management through Distributed System Manager 2010.
• Find  your web service in Distributed System Manager under NI_WebServices
• Right-click your web service and select Delete Server

Please let me know if this information aids in your troubleshooting. We shouldn't under any circumstances should have to require a reinstall to fix the Application Web Server.  If there is a bug that could cause that I hope we can work together to identify it, so LabVIEW R&D can address it as quickly as possible.  

[soren_jensen]

Mark,

Naturally the webservice runs on port 80. Unless you run on port 80 you need to specify the port in the URL. Please notice the slight change in the URL to obtain the regular 404 error, I belive you misunderstood my statement about how to obtain the 404 error. The latter was just to indcate that calling a webservice with an incorrect URL should return a 404 error, not crash the webservice.

I cant currently send you my code, since I dont have access to my server right now. But I suspect that any type of VI will cause this problem, so it should be easy to reproduce. Please let me know if you can do this.

/søren

[MarkBlack · Accepted solution]

Hi Soren,

I was able to reproduce the crash you described and I have filed Corrective Action Request 256559.  Because this particular crash has an easy work-around I do not expect it to be addressed in 2010 SP1.  I also want to point out for this crash to occur you must not only include the ".vi" extension for the web method, but you also must use "?" as your query separator.  In instances where you use the terminal method for your VI and you use "/" to separate your query instead of "?" you will receive a 404 not found error.

Please let me know your thoughts.

[soren_jensen]

LabVIEW R&D,

Thanks for a quick responce. The workaround I found was to always include the .vi into the URL binding name, thus avoiding the accidential call of URL+.vi.

Unfortunately all is not well here. Using the same procedure as described earlier, by just calling a URL from Internet Explorer, I experienced a crash of the app. webserver that made it impossible for me to restart it.

Only after erasing all traces of LabVIEW from my machine (using msi blast) and aftwards reinstalling LV2010 I was able to get the app. webservice restarted.

Before this msiblast+reinstallation, the app. webservice would only start breifly and then stop again (without any type of error dialog).

This could be a problem caused by the combination of both LV2009+10 being installed on the same machine, or it could be something else, I cant tell. The severness of this failure, prevented me from testing it any further. Reinstalling LabVIEW takes a looong time. However, perhaps a bit further investigation into this topic is a good idea.

Thanks again for helping me.

/søren

[MarkBlack]

Soren,

I am a little confused by your last post.  Are you saying the App Web server is stopping when you call any web service you have deployed?  Or is the App Web server stopping shortly after boot?  

Regardless I do not believe the solution will require you to reinstall LabVIEW, nor do I believe this was necessary the first time you uninstalled and reinstalled LabVIEW.  I appologize if this was something that was frequently recommended to you in the past.  In many cases this style of brute force problem solving is unnecessary and leaves us without the true solution to the problem.

If you have not already please follow the instructions in my earlier post to remove any previously deployed web services on your system.   You should also make sure LabVIEW 2009 is not running.  If LabVIEW 2009 is not running neither is the web server that runs 2009 web services.  This has changed in 2010.  Because the application web server is a process unique to LabVIEW, LabVIEW 2010 does not need to be running in order for web services built in 2010 to be accessible.  

If you believe you have steps to reproduce this failure with a simple web service VI, please share them with me so I can attempt to reproduce this problem.

[james brunner]

@BLAQmx:

Sorry, I may be a bit slow here.  Could you describe the "easy work-around" for CAR 256559?  I'd like to ensure that clients cannot crash our web server, but I did not find anything other than this thread when I searched for the CAR on the forums.

Thanks in advance.

--

James

[MarkBlack]

The work around is to ensure you do not include ".vi" in your web method names.  EG:

http://host/webservice/webmethod.vi?requestvar=1 <----This can result in a crash

http://host/webservice/webmethod?requestvar=1 <----This can will not result in a crash

Also, from my earlier post....

" I also want to point out for this crash to occur you must not only include the ".vi" extension for the web method, but you also must use "?" as your query separator.  In instances where you use the terminal method for your VI and you use "/" to separate your query instead of "?" you will receive a 404 not found error (instead of a crash)."

Let me know if this doesn't clarify everything for you.

[james brunner]

Thanks, Mark, I really appreciate the quick follow up.

I was having problems understanding that the problem was the naming of the web methods (e.g., adding a ".vi" in the method name could result in the crash).  At first it looked to me as if you could create any valid web method name, but then call the URL for the method with an additional ".vi" (and as you suggested, the "?" query separator), and the web server would crash.  Obviously we want the server to be robust to any request, so this kind of scared me.

Thanks again for the clarifiation.

--

James

[MarkBlack]

---

"Obviously we want the server to be robust to any request, so this kind of scared me."

---

I whole heartedly agree.  Because this issue results in a crash it will be a priority for our development team to address this bug.  If you ever run into any other web server crash, please do not hesitate to contact NI to report it.