I think this comes with experience... when you're facing a very odd issue, chances are that you're watching at a BUG in action. For example, last time it was a WebService call over GPRS which seemed to be processed successfully on the server, but returned an InvalidOperationException on the device. The problem was not with the GPRS Operator, it was not specific to any OEM-customization and it wasn't specific to Windows Mobile's version. So it must probably have been something with the NETCF itself...
Before starting deeply troubleshooting in whatever direction (in this case it might have been network traces to look at SOAP messages, instrument the code, try to reproduce with Cellular Emulator...), you may verify if the issue is reproduced when the application runs on top of the NETCF v3.5. Note that a re-compilation of the code through VS2008 is NOT needed – you can use a .CONFIG file to instruct the CLR to load v3.5 assemblies even for an application developed against v2. See here for a post by David Kline about this. The configuration file must be named “yourApplication.EXE.CONFIG” (note the “.EXE”) and must be placed in the same folder of the “yourApplication.EXE” (in a NETCF Loader Log this is what's called "Policy file"), and it must contain:
To make sure the application is running on top of the v3.5, you should check if the mscoree3_5.dll is a loaded module. If you can't attach Visual Studio's debugger and can't even connect the device to a PC with Remote Tools installed (Remote Process Viewer), then you can for example use JShell directly on the device, which is a sort of command-line tool available through the "Windows Mobile Developer Power Toys". Remember to completely exit the application before running the test or even better to soft-reset the device.
Obviously you need to install the NETCF v3.5 on the device before doing so: the redistributable is available here.