I’ve had a couple of clients that ran into a problem where their SMS Message interceptor would fail to fire. (For an introduction to this pretty cool technology see here.) This was a hard to track down problem, because the interceptor would work on some devices, and the emulator, but not on a handful of devices. Because this worked on several devices, it seemed the code was without errors.

We resolved this by determining if any of the existing SMS interceptors were interfering with this one. SMS Interceptors fire in a chain with each one handing off to the next. That is they should hand-off. If you are implementing a native code interceptor using IMailRuleClient, you can stop the message processing by setting the handled flag to MRC_HANDLED_DONTCONTINUE. This prevents any further processing of the message. However, this flag should ONLY be used if the message you are receiving is private to your application / interceptor. If other interceptors could possibly process the message, you should set the handled flag to MRC_HANDLED_CONTINUE or MRC_NOTHANDLED. For managed code, if you would like the message to be available to other interceptor applications, create the MessageInterceptorinstance passing the InterceptionAction.Notify enumeration value to the MessageInterceptor constructor.

You can test for interfering interceptors by going to [HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Svc\SMS\Rules] and set each rule to ‘0’ until the problem goes away. The last rule you change to ‘0’ before the problem goes away will be the problematic rule. Note that you need to soft reset the device after changing the registry key.

For example:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Svc\SMS\Rules]

"{27E9801F-330B-4c6a-A7BF-A670D8C53C5D}"=dword:00000001

"{E85FD9C3-4F5E-4c75-8C21-0F850274DEF5}"=dword:00000001 <-
Change to 0 to test

Once you have located the problematic rule, you can get more information on it (for example, the DLL name) by searching for the GUID underneath HKEY_CLASSES_ROOT\CLSID.

Thanks,

Mike