Windows CE Web Server Development Tricks


Let's say that you have to write some server-side scripts that runs on the Web Server of your Windows CE device.  You've read about the various server-side scripting technologies Microsoft supports here.  You've come up with a design and you're about ready to start coding.  I'll try to lay out how to make your life easier for the development stage below.


* If you're using ASP, turn on verbose error messages
For some of the Windows CE 4.x line, we turned off verbose ASP error messages by default.  On any error you got something like "The ASP Page encountered a parse error".  As you can imagine, this isn't very helpful if you're trying to debug an ASP page.


To workaround this, you can re-enable ASP verbose messages via the registry.  Instructions are available here.


In WinCE 5.0 and beyond, we changed the default since people weren't finding out about the registry setting and were having a horrible time.


* If you modify an ISAPI extension DLL, you don't need to reboot the device
By default, the web server leaves ISAPI dlls in a DLL cache for 30 minutes after their last use.  This makes them run more quickly, but is painful if you need to make a change to the DLL.  I know a lot of people disconnect their debugger, recompile the DLL, and then reboot the device.  That can be a very lengthy process.


It's much easier than that!  Just run "services refresh HTP0:" from a command prompt on the CE device (or write an app to call CreateProcess to do it).  This causes the Web Server to reread all its registry configuration settings and also to unload any ISAPI DLLs it has loaded.  Note on Windows Mobile 5 you'll have to change the services.exe registry key to re-enable command line parsing, which it turned off by default.  Note this will work on CE 4.0 and above only, not on CE 3.0.


* If you change an ASP DLL, you probably do need to reboot the device (if you're not clever)
Unfortunately running "services refresh HTP0:" will NOT unload COM DLLs that ASP loaded.  The issue is that COM itself, and not services.exe, maintains this DLL cache.  (This is tied to the infamous CoFreeUnusedLibraries.)  You can try killing the services.exe process itself and restarting it.  Sometimes it works, other-times it doesn't, and you'll hit some obnoxious but (in my experience at least) harmless ASSERTs killing services.exe.


A more clever way of going about this is to write a harness executable to call into your COM objects directly and test what you're interested in trying out, simulating as if it was called from ASP.  Only after your COM DLL is reasonably stable should you do hard-core test from within an ASP page.  Of course you want to do basic ASP tests at each stage of the development to make sure there won't be any nasty surprises about your COM object & ASP page interaction at the last moment.


* Consider developing on IIS, but be careful!
Microsoft does not ship any sort of Visual InterDev tool for the CE Web Server.  It's not possible to step through ASP pages in a debugger on CE.  However, if you have IIS you should be able to make your ISAPIs and/or ASP pages and COM objects compile and run there.  On this platform you can use the better development environment and then port your work over to Windows CE.


Be very careful doing this!  Make sure you don't accidentally use IIS only features and then when you port your work to WinCE discover they're not supported.  Just like running the ASP COM object DLL in a test-only process, frequently test that your web pages work as you'd expect on WinCE throughout the development process.


* Setting break-points
If you want to set a break point and you're using Platform Builder, first break into the debugger and only then set or unset the break point.  Just setting the breakpoint when the device is still running will not make the break point take effect until the next time you break into the debugger.


[Author: John Spaith]

Comments (2)

  1. Chuck says:

    I’m sorry to bother you, but I am so lost and I really need some help.  I’m new to ASP and to Windows CE 6.0. I’m building my application using Visual Studio 2005 and Platform Builder so that I can test the app in an emulated CE box before deploying to the actual hardware which is still being designed and built.

    One facet of this application is a small web-interface created with ASPs. But for some reason my CE webserver will not serve ASPs. It serves HTML pages just fine, no complaints, but try to hit ANY asp page and it kicks back an HTTP 501 error with the message "This method is not implemented." According to Microsoft, this happens if the Httpisapi, Httpextn, or Httpasp components are not included when building the webserver. But in my PlatformBuilder "catalog" there is no option to include these components by name, only a single checkbox for "ASP support" which I have of course checked off. I have located ASP.DLL and JSCRIPT.DLL on the CE box, so ASP support is definitely being built and deployed.

    Yet I still get this error, and have been for about 3 days now. I have confirmed that the problem is on the server side by testing with both IE, Firefox, and IE from a remote computer. I am reaching my wits end. Can you help? Googling hasn’t turned up anything useful.

  2. cenet says:

    Chuck – my apologies for delay, I had been on extended vacation & this slipped through the cracks.  http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx has newsgroups, which are usually best means of tech questions like this.

    I have no clue what’s up, you already anticipated my first ideas for investigation.  If you still need help here, please drop a debug HTTPD.dll & ASP.dll into your image (or build a fully debug image) — http://blogs.msdn.com/cenet/archive/2007/04/09/how-to-drop-a-debug-dll-into-a-windows-ce-device.aspx.  Then post the output on a newsgroup and I can take a look.

Skip to main content