WinCE Stack 异常

在使用 VS2008 开发 WinCE7.0 的程序,测试发送 WM_COPYDATA 消息时,发现在 Debug 模式下接收方可以正确的接收到消息,消息中的数据也是正确的。换成 Release 模式后,接收方也能接收到消息,但有一接收方不进入数据解析函数。

两个消息的接收方,一个是用 SDK 开发的 WinCE 程序(称为 C 程序);另一个发送到发送 WM_COPYDATA 消息的自身应用。先将 WM_COPYDATA 发送给应用、再将同样的消息发送给 C 程序。

无论是在 Debug 模式,还是 Release 模式,C 程序都可以接收到正确的消息和数据。

由于一般使用 Debug 模式进行程序的开发与调试,在程序开发结束时才切换到 Release 模式,是否是在使用 Debug 模式开发过程中,修改了什么导致两者表现不一样?

由于已经可以确认代码没有问题,所以怀疑是系统的 Stack 出现问题。查看工程属性:配置属性/链接器/系统/堆栈保留大小,发现 Debug 模式下已经修改为默认值的 4 倍,即 262144,而 Release 模式下仍然在使用原始的默认值 65536。

修改此项的设置值为:262144 后,编译运行,一切正常。

OK 了。

代码逻辑(由于 Client 是正确的,不再分析 Client 的代码逻辑):

 1 // 消息发送处消息打包与发送的过程
 2 COPYDATASTRUCT cs;
 3 FilesList FileInfo;   // 待发送的数据,为一结构体,大小为 2624 字节
 4
 5 // 给结构体 FileInfo + cs 赋值
 6 ......
 7 cs.lpData = &FileInfo;
 8
 9 // 消息发送
10 if(NULL != hServer)
11 {
12   ::SendMessage(hServer,WM_COPYDATA,256,(LPARAM)&cs);
13 }
14
15 if(NULL != hClient)
16 {
17   ::SendMessage(hClient,WM_COPYDATA,126,(LPARAM)&cs);
18 }
19
20 // Server 消息接收
21 LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
22 {
23   ......
24
25   switch (message)
26   {
27     case WM_COPYDATA:
28       // Leo 出错时下面这句 LOG 有输入: [Agent]WndProc - message received from test app: 0x4A(256,738496)
29       RETAILMSG(1,(L"[Client]%s - message received from server: 0x%X(%d,%d)\r\n",CString(__FUNCTION__),message,wParam,lParam));
30       {
31         if(TRUE == ProcessMsgRcved(message,wParam,lParam))
32         {
33           ......
34         }
35         else
36         {
37           ......
38         }
39       }
40       break;
41       ......
42       default:
43           return DefWindowProc(hWnd, message, wParam, lParam);
44     }
45     return 0;
46 }
47
48 BOOL ProcessMsgRcved(UINT message,WPARAM wParam,LPARAM lParam)
49 {
50   BOOL bRet = TRUE;
51
52   switch(message)
53   {
54   case WM_COPYDATA:
55     {
56       COPYDATASTRUCT *pCs = (COPYDATASTRUCT *)lParam;
57       // 由 LOG: [Agent]WndProc - message received from test app: 0x4A(256,738496) 知 pCs 不为空。
58       if(NULL != pCs)
59       {
60         // Leo 出错时没有下面这句 LOG 输入
61         // 按程序正常的流程,应该走到此句 LOG 才对!
62         RETAILMSG(1,(L"[Server]WM_COPYDATA - %d,%d,0x%X\r\n",pCs->dwData,pCs->cbData,pCs->lpData));
63
64         ......
65       }
66     }
67   }
68 }  
时间: 2024-08-07 10:44:32

WinCE Stack 异常的相关文章

谈谈前端异常捕获

作为一个前端开发人员,每次看到浏览器控制台信息里面红通通的报错信息是不是都很紧张......不要怕,下面我们就来讨论一下前端的异常捕获. 异常捕获,相对于其他知识点可能没那么被重视,特别是对于前端程序员.但不得不说,这又是一个不得不面对的知识点. 为什么要捕获异常 首先,我们为什么要进行异常捕获和上报呢? 正所谓百密一疏,用程序员的话来说就是:天下不存在没有bug的程序(不接受反驳 ?? ).即使经过各种测试,还是会存在十分隐蔽的bug,这种不可预见的问题只有通过完善的监控机制才能有效的减少其带

node 进阶 | 通过node中如何捕获异常阐述express的特点

node如何捕获异常 node基于js的单线程,有了非阻塞异步回调的概念,但是在处理多个并发连接时,并发环境要求高,最重要的是单线程,单核CPU,一个进程crash则web服务都crash,但是为什么node还这么火?甚至有了Node工程师这个岗,肯定就是node有自己crash之前与之后的解决方法,比如捕获异常 问:nodejs如何捕获异常?答:回调函数中有err形参,console.log出来,这是我之前回答别人问题的答案,但是自从我这几天看了如何捕获异常,才知道捕获异常的精髓就是不要让服务

Spark2.0机器学习系列之8: 聚类分析(K-Means,Bisecting K-Means,LDA,高斯混合模型)

在写这篇文章之前,先说一些题外话. 许多机器学习算法(如后面将要提到的LDA)涉及的数学知识太多,前前后后一大堆,理解起来不是那么容易. 面对复杂的机器学习模型,尤其是涉及大量数学知识的模型,我们往往要花费大量的时间和精力去推导数学算法(公式),如果过分沉湎于此会忽略了很多背后也许更重要的东西,正所谓只见树木,不见森林,而这是缺乏远见,是迷茫的. 我们需要深入理解模型背后的逻辑和所蕴含的或简或繁的思想.某些思想甚至可能是很美的思想,很伟大的思想.这些理解,使得面对复杂的问题时候,面对陌生问题时,

JVM内存模型及String对象内存分配

昨天看了一篇关于<Java后端程序员1年工作经验总结>的文章,其中有一段关于String和StringBuffer的描述,对于执行结果仍然把握不准,趁此机会也总结了下JVM内存模型. 1.JVM运行时数据区域 关于JVM内存模型之前也了解过一些,也是看过就忘,好记性比如烂笔头,记下来吧.参考此文章http://chenzhou123520.iteye.com/blog/1585224 图1 JVM运行时数据区域 (1).程序计数器(Program Counter Register): 程序计数

JVM 运行时数据区详解

一.运行时数据区: Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同数据区域. 1.有一些是随虚拟机的启动而创建,随虚拟机的退出而销毁,所有的线程共享这些数据区. 2.第二种则是与线程一一对应,随线程的开始和结束而创建和销毁,线程之间相互隔离. java虚拟机所管理的内存将会包括以下几个运行时数据区域 二.数据区详解 1.程序计数器(Program Counter Register) 也叫PC寄存器是一块较小的内存空间,它的作用是存储当前线程所执行的字节码的信号指示器.

【转】jvm 内存模型及内存调优

一,JVM内存模型概括 还有一个寄存器,线程运行于其上面 1.程序计数器 记录线程的执行位置,线程私有内存,唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域 2.线程栈(VM stack) 栈的默认大小是1M -Xss2m 这样设置成2M 异常 :Fatal: Stack size too small 异常的引起一般是线程数目太多 3.本地方法栈(native stack) 即为一些Native方法分配的stack 异常:java.lang.OutOfMemo

通俗易懂理解JVM结构

通俗易懂理解JVM结构 说明:本篇内容是结合网上各位大牛的关于JVM的文章,通过作者的理解,希望以一种比较易懂的方式,让各位朋友们理解JVM到底是怎么一回事儿,其中部分图片和内容引用来自于网络,如有雷同,请见谅~~ 一.JVM内存区域模型是啥样? 这个是JVM大致的内存分布模型,看起来比较直观: 这个是更精细化的JVM内存模型,区别主要是方法区和堆是公共内存区,其他是私有的: 1.方法区: 也称"永久代" ."非堆", 它用于存储虚拟机加载的类信息.常量.静态变量.

Java异常的栈轨迹(Stack Trace)

捕获到异常时,往往需要进行一些处理.比较简单直接的方式就是打印异常栈轨迹Stack Trace.说起栈轨迹,可能很多人和我一样,第一反应就是printStackTrace()方法.其实除了这个方法,还有一些别的内容也是和栈轨迹有关的. 1.printStackTrace() 首先需要明确,这个方法并不是来自于Exception类.Exception类本身除了定义了几个构造器之外,所有的方法都是从其父类继承过来的.而和异常相关的方法都是从java.lang.Throwable类继承过来的.而pri

JS 异常: Uncaught RangeError: Maximum call stack size exceeded

遇到了这个js异常, 总是吧浏览器搞崩溃,这是什么原因呢? 开始我也只能想到死循环, 也许是哪个条件判断写错了,其实不是.经过google,发现了一篇文章,内容请看: ================================================================= 文章地址: http://www.zizhujy.com/blog/post/2012/03/18/Uncaught-RangeError-Maximum-call-stack-size-exceed