Windows Mobile 6 间歇性连接状态 NOPATHTODESTINATION
在 Windows Mobile 6 设备上，我们尝试打开互联网连接。 这通常有效，但有时我们会得到返回代码 0x80004005，状态为 CONNMGR_STATUS_NOPATHTODESTINATION。 当这种情况发生时，它会继续发生，但如果您在设备上启动 IE，它将进行连接，然后我们对 ConnMgrEstablishConnectionSync 的调用就会起作用。 我们无法找出导致这种情况发生的原因，目前它似乎是随机的（尽管我怀疑它不是）。 有什么提示吗？
我们的代码基本上是这样的：
CONNMGR_CONNECTIONINFO connInfo;
DWORD dwStatus = 0;
memset(&connInfo, 0, sizeof(connInfo));
connInfo.cbSize = sizeof(connInfo);
connInfo.dwParams = CONNMGR_PARAM_GUIDDESTNET;
connInfo.dwFlags = CONNMGR_FLAG_NO_ERROR_MSGS;
connInfo.dwPriority = CONNMGR_PRIORITY_HIPRIBKGND;
connInfo.guidDestNet = IID_DestNetInternet; /* Connect to the "Internet" network */
hr = ConnMgrEstablishConnectionSync(&connInfo, &s_hConnection, 120 * 1000, &dwStatus);
On a Windows Mobile 6 device we are trying to open an internet connection. This usually works but sometimes we get a return code of 0x80004005 with a status of CONNMGR_STATUS_NOPATHTODESTINATION. When this happens it will keep happening but if you launch IE on the device, it will connect and then our call to ConnMgrEstablishConnectionSync works. We have not been able to isolate what causes this to happen, it currently appears to be random (though I suspect it isn't). Any hints?
Our code looks basically like this:
CONNMGR_CONNECTIONINFO connInfo;
DWORD dwStatus = 0;
memset(&connInfo, 0, sizeof(connInfo));
connInfo.cbSize = sizeof(connInfo);
connInfo.dwParams = CONNMGR_PARAM_GUIDDESTNET;
connInfo.dwFlags = CONNMGR_FLAG_NO_ERROR_MSGS;
connInfo.dwPriority = CONNMGR_PRIORITY_HIPRIBKGND;
connInfo.guidDestNet = IID_DestNetInternet; /* Connect to the "Internet" network */
hr = ConnMgrEstablishConnectionSync(&connInfo, &s_hConnection, 120 * 1000, &dwStatus);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Windows Mobile 连接管理器是一个巨大的 PITA。 如果您通过 IP（例如“255.255.255.255/其他”）而不是服务器名称指定网络地址，您是否会收到相同的错误？
我的猜测是，您可以使用以下方法之一按需重现缺乏连接的情况：
Windows Mobile connection manager is a huge PITA. Do you get the same error if you specify the network address by IP (e.g. "255.255.255.255/whatever") instead of by server name?
My guess is you could reproduce the lack-of-connection on demand with one of these methods: