Help! WSDAPI crashes after my service method returns!

  • Article

I'm going to take a quick detour from WSDAPI 101 to comment on an issue you may have seen when developing and testing a service or client based on WSDAPI.

The symptoms of this crash
This problem may arise in two scenarios:

  1. You have a service object hosted by the WSDAPI device host.  A wire message triggers a call into this service method.  Shortly after your service method returns, your application crashes.
  2. You have a client-side event sink and have subscribed to events from a service.  When an event arrives, WSDAPI enters your event sink method.  Shortly after your event sink method returns, your application crashes.

In both cases, this problem only applies to applications running on the desktop version of WSDAPI (i.e., under Windows Vista or Server 2008).  This does not apply to WSDAPI-based apps running under Windows CE. 

You may see this manifest in a handful of different ways:

  • If it's under a debugger, your application may issue an Access Violation (AV).
  • If not, your application may crash and trigger a Watson error.
  • You may receive a Data Execution Prevention popup.

The explanation behind the crash 
In all cases, the cause is the same: a difference in the calling convention is causing your service method (or client-side event sink) to corrupt the stack when it returns control to WSDAPI.  WSDAPI expects that your service method will use the __stdcall calling convention, but it's common for applications to be compiled with __cdecl (or even __fastcall) conventions, especially if built in Visual Studio.

How to fix this crash
To fix this problem, you need to change your compilation options to use __stdcall (/Gz) instead of other calling conventions.  Since this problem is most prevalent in the Visual Studio build environment (which defaults to __cdecl), here are directions for fixing this in VS 2005:

  1. In the Solution Explorer, right-click on your project and select Properties
  2. Navigate to Configuration Properties, C/C++, Advanced
  3. Be sure to select All Configurations in the Configuration drop-down
  4. Change the Calling Convention dropdown to __stdcall (/Gz)

At right is a screenshot that describes this property page and the changes you need to select.  The areas of interest are highlighted in red.

We're also going to fix this for the next version of WsdCodeGen, so you can use whatever calling convention you'd like in your application.  Until then, changing this option will allow your service methods to safely return without crashing the application.

Comments

  • Anonymous
    October 14, 2008
    Hi Sir, Please provide me the procedire how to create new webservice for windows CE 6.0 device. waht framework i need to use in VS 2005.

  • Anonymous
    October 21, 2008
    Hello rama- The steps to create a DPWS device using WSDAPI on CE 6.0 are fairly well-documented on MSDN.  You can start at the CE WSDAPI reference page (http://msdn.microsoft.com/en-us/library/bb667074.aspx), which will lead you to the tools you need to create a device image. --Dan

  • Anonymous
    December 22, 2008
    The comment has been removed

  • Anonymous
    August 28, 2011
    I am facing problem while running sample application "StockSquote" on windows 7 machine. This application is based on WSDAPI (Web Services for Devices API). Problem:  The source code location is C:Program FilesMicrosoft SDKsWindowsv7.0Sampleswebwsdapistockquote on windows 7 machine.  I compile the project and run the StockQuoteService on one Windows 7 machine and StockQuoteClient on another Windows 7 machine. I used urn:uuid based address mechanism to host and access the service. Note: (Both machines are in same subnet and are connected directly without any router.) Host Machine Ip Address: 192.168.0.10 Host Machine Subnet mask : 255.255.255.0 Client Machine Ip Address: 192.168.0.11 Client Machine Subnet mask : 255.255.255.0  The client application is failing while calling method "GetLasttradePrice". Steps Tried to diagnose the issue: I followed all the steps given in msdn.microsoft.com/.../bb648708%28VS.85%29.aspx. Still I could not figure out what is the reason behind this failure.

  • Anonymous
    August 29, 2011
    Hi Santosh- The debugging steps contain all of the generic steps we could think of to diagnose this type of failure. You didn't mention if you had inspected network traces to compare your traffic to other example traffic on the network--I suggest following this step to determine why you are unable to invoke methods on your device (either because discovery is not working, or because method invocation isn't working). --D

  • Anonymous
    August 29, 2011
    Hi Dan, I am not able to run the rest of the sample applications like FileService. Proxy creation on client side is successful and I can see Hello, Resolve, Resolve Matches messages. But while calling the methods call is not reaching to service. I had captured the network traffic using wireshark. After your suggestion i did it with Netmon. In soap response I could see below message: "no route can be determined  to reach the destination role defined by the WS-Addressing To" I also tried it with Win CE 7 Device (service on win CE and client on Win 7), but getting the same issue.

  • Anonymous
    August 30, 2011
    Hi Santosh- It sounds like the problem is on the device/service side. Unfortunately, but I can't debug specific problems like this--please contact Microsoft developer support if you would like assistance. Thanks --D