...找详细错误信息 有异常代码c0000005 怎么办
发布网友
发布时间：2024-08-07 04:53
共1个回答
热心网友
时间：2024-08-20 17:29
【小聊VFP9与致命错误c0000005】
天哪，太久没来了！以至于好半天才想起如何发表新帖：）
这份帖子主要在讲述“致命错误——C0000005”，它是什么，为什么会出现，何种情况下将出现，以及如何避免之。请根据您的口味选择是否浏览之。
昨夜又见论坛上寻问C0000005的帖子，是关于Visual Foxpro 9.0 版本的，这引起了我的注意。
本以偷懒的态度草草回复之，然而接下来网友的追问使我自知偷懒的后者便是语义表达不到位，便索性连夜写下此主题帖。但仍以简练为主，请大家多担待！
在文章中，若一整段的文字均被括入括号中，则说明它不过是与主题无关的小常识。
c0000005错误发生的诱因主要分为四大类：
1、自由表存储载体的缺陷（主要体现在VCX、VCT，SCX和SCT上）。
2、第三方监控性质的软件。（如：防毒软件在内存即时监控状态下、词霸软件在全屏拾取模式下等）；
3、Visual Foxpro 自身的代码漏洞；
4、硬件因素。
先说第一大类：
同数据表一样，在Visual Foxro 9.0 版本中，自由表也支持了原子事务机制，这并非主要是为了满足客户的需要，而以稳定VFP9自身为主。我们都知道类与表单的代码多以物理形式为自由表的VCX、VCT，SCX和SCT文件格式存储，在IDE设计模式下，代码被VFP后台以独占的、开放式自由表缓冲的模式存取。然而您应该敏感地注意到：自由表是不支持事务机制的（低于9.0版本的Visual Foxro）。也就是说，遇到停电或操作系统异常时，它们同样会面临表头损坏、低级链接错误、记录指针错误偏移的风险。Microsoft Visual Foxpro 开发组没有将VCX、SCX设计为依赖于数据库的数据表的形式，原因不难理解——如果一个表单文件中，包括表单本身在内的任何一个控件都不依赖于用户自定义派生类的话，那么该文件应该可以被独立地拷贝与打开。
如下的常识我们都需要知道：
无论是在设计模式还是在运行模式下，Visual Foxpro的Runtime会随时将客户脚本读取到内存体中，并交由词法分析器、语法分析器和语义分析器来分析、解释、处理这些代码。
（通常情况，在编辑模式下，我们的脚本代码已经被Visual Foxpro词法分析器进行了第一遍的过滤；在编辑完一个prg或表单或类文件后，若按下Ctrl+W组合键将在保存它之前调用语法分析器来试图检查其中的错误（注意“词法”分析器与“语法”分析器的不同），然后程序界面将自动被关闭；而若按下Ctrl+S组合键保存后，再手动退出时，这种情况下将不会调用语法分析程序。）
如果你的脚本保存在自由表形式的SCX、SCT、VCX、VCT文件中，Visual Foxpro会通过表的记录指针提取对应备注文件里的程序脚本（那里或许包含了某些事件或方法的代码），Visual Foxpro会通过调用C语言的sizeof()来判断字节的长度，根据长度提取字节，最后将长度的返回值与实际代码以参数的形式传递给语义分析器来解释执行。然而在一些情况下，会发生sizeof()判断的字节长度与实际的长度不一致的情况。
倘若sizeof()判断的字节长度与实际的长度不一致，将会发生内存的溢出，这个致命错误被Visual Foxpro异常处理器捕获后，将抛出“致命错误－C0000005”的信息。
“致命错误”是字符常量，“c0000005”是一个变量，c0000005不是VFP的错误编码，而是得到Windows消息环所传递过来的错误消息的半加工品。它的原始状态是16进制的0xC0000005，VFP通过相关的转换函数转换成字符串的形式，以便通过界面描述给用户。
那么什么情况下会出现sizeof()判断的字节长度与实际的长度不一致的情况呢？主要有两方面的主导因素。
1、我们前面铺垫过了，VCX、VCT，SCX和SCT文件都是自由表，都有可能在设计时被无意的损坏。
倘若表头被损坏，您会在试图打开它们的时候收到VFP系统的无法打开该表单的信息；但倘若低级链接错误、记录指针错误偏移，您就不会得到任何VFP的提示，因为VFP系统自己也不知道这一点，就像您一样。于是直到程序运行时，才会收到令人惊愕的致命错误信息——语义分析器工作时内存被溢出。
在一些“致命错误－C0000005”的信息框中，您会收到似乎更详细些的信息，指示您程序出错的地方。那通常是包含在SCX、SCT或VCX、VCT里某些行的代码。
千万不要被误导，并不是您的程序代码编写有问题，而是隐藏在标识符之外的、看起来好像是空格、回车的空白段，那里隐藏了低级链接的错误、或Unicode的错位排序（下面马上就会讲述到），用Shift+方向键将整行全选，然后按Delete键删除之，最后老老实实地将原行代码重新书写一遍即可（切记：用Shift+方向键将整行全选，然后将该整行彻底清除）。
2、Unicode。
从Windows98升级过来的VFP程序员似乎都曾有过这样的困惑：为什么Windows2000以上版本的VFP程序会如此的不稳定，以至于频繁出现“致命错误——C0000005”？
您现在上网用的计算机的操作系统是WIN2000或WindowsXP吗？如果是，不妨亲自做这样一个试验：
打开记事本程序，输入“联通”，然后保存后关闭该文本，再重新开打，看到什么了？
是的，当年WIN2000操作系统的流行时，Visual Foxpro开发组并没有彻底改正语义分析器代码的漏洞。
好的，第一大类我就阐述完了。如何避免它呢？
总的应该说很麻烦，有两种途径供您选择：1、修改VCX、SCX表国际代码页的编码，将简体中文编码改为英文编码；
2、我所推荐的方法是尽量用prg。你可能会认为这样做很麻烦，但作为程序员，您应该更加专业一些。您可以备份可视化的表单或类文件，但在程序正式发布前，最好最大限度地转化为prg程序。倘若以后需要修改程序，通过备份的表单或类文件进行可视化编辑，然后再次转化为prg发布之。
顺便告诉您一个小窍门：
在IDE设计模式下，我们或许会突然遇到“致命错误－C0000005”袭击，因为表单是以独占的、开放式自由表缓冲的模式交互的，所以此前未经保存的信息都将被丢失，这您是知道的，通过刚才的讲述，您还知道了这或许会面临表被损坏的风险，从而进入了一个“致命错误－C0000005”潜在引发今后“致命错误－C0000005”故障的恶性循环。
小窍门就是，您千万不要条件反射地去触击那个“确定”按钮！那不过只是Visual Foxpro系统所捕获的异常罢了，它不是真“致命”的，Visual Foxpro系统仍在运转中，也就是说，它还在正常地接收着Windows操作系统不断发送来的消息。这时，请您点开Windows桌面最左下角的“开始”按钮，选择“重新启动计算机”或“关闭计算机”，Windows在试图关闭电脑前，会先检查是否有尚在运行中的应用程序，它会发现一个叫Fox的先生尚未退场，于是便发送清场的消息给Foxpro，Visual Foxpro其实还在正常的运转中，它接收到这条消息后，会调用自身的退出机制试图退出，而自身的退出机制会发现尚有正在编辑的表单，便会发出“需要保存修改吗？”的询问消息，这时候，您选择保存，就可以了！
千万注意了！这段过程大概只有5秒钟的时间！因为为了防止死循环的情况出现，Windows会在等待几秒钟对方不应答的情况下强行终止程序，那时候，就真正退出整个Windows系统了。所以您一定要眼疾手快！
（说到异常处理，便自然地想到了Vfp9新加的异常处理Try机制，事实上倘若不是开发OLE远程服务的DLL，您就没有必要就使用它。因为VFP为您提供的On error或Error事件，其脚本解释程序代码实质上就是C++的异常处理机制，在您熟练地使用VFP错误处理程序时，实际上就等于在使用C++的异常处理程序了。）
第二大类是第三方监控性质的软件。如：防毒软件在内存即时监控状态下、词霸软件在全屏拾取模式下等。其实防毒软件本身并不与VFP产生冲突，但有一个例外，就是内存即时监控（请注意：防毒有许多即时监控，唯有内存即时监控才会与有时候与VFP发生冲突）。
所谓内存即时监控并不是去读取内存条中的数据，谁也没这么大的本事，它的原理就是专门关注于Windows系统目录下的system32子目录中的程序文件在运行中的状态。
我们知道，在Visual Foxpro 8.0 版本以前，其运行时刻文件是安装在system32目录中的；而向最终客户发布你的应用程序时，默认情况下，无论是VFP什么版本，其运行时刻文件均会被拷贝到system32目录中去。
防毒软件的内存即时监控的工作原理是这样的（这是瑞星公司首创的，瑞星软件也是狐友受害最深的）：1、它会在Windows后台运行一个类似于Windows的模拟机（这有点像任天堂游戏模拟机和一些手机模拟机，还有现在时髦的Linux下的Windows模拟机）；2、它运行一个循环，挨个监视system32目录下的exe及dll文件是否被调用；3、倘若被调用，就拷贝一份到瑞星自己创建的隐含、系统目录中去，然后在那个模拟机中运行之，以便模拟其在Windows实际运行中的状态；4、在模拟运行中，看它是否有病毒发作的特征；5、如果有，就查找病毒特征码数据库；6、若在数据库中，找到了对应的特征码，便确定特征码所对应的病毒名称，否则，就按未知名的新病毒处理（这就是为什么有的VFP加密软件会被防毒软件误报病毒）。
由于VFP应用程序与运行时刻DLL库交互的太频繁了，使防毒软件的那个循环程序不断捕捉到VFP运行时刻库在进行新的数据响应，防毒软件便不断地试图拷贝它，以便进行新一轮的模拟。但你知道，无论是DBF还是SCX等等，只要是独占方式打开的（SCX与VCX总是被独占的，而DBF取决于你的设计），就不能被其它的程序所访问。但在Windows操作系统中，防毒软件所调用拷贝程序的系统优先级要高于你的程序的优先级，所以你的VFP程序会最终产生致命错误。
如何避免它呢？你可以简单地关闭防毒软件，但如果让客户也像你这样做的话，就显得太不专业了！
聪明的你恐怕现在已经想到了：只要在发布你的应用程序时，将那些运行时刻库放到应用程序目录下就可以了！
同样，词霸软件本身也不会与你的程序发生冲动，只是在全屏取词的模式下才会如此。不过你的用户几乎不会遇到，因为你的程序几乎不会让他们在程序界面状态下直接打开某个数据表——仅在词霸的全屏取词程序试图通过独占模式下的数据表的窗口句柄，来访问里面的文本属性时，才会与其独占模式发生冲突。
第三大类是Visual Foxpro 自身的代码漏洞。比如VFP6.0版本的Textbox控件等等。现在版本的VFP，这样的错误少多了，我们的话题就不再展开。
第四大类是硬件因素。
有些细节问题是最不被人所注意的。但其足以铸成大过。
“致命错误C0000005”是内存泄漏的症状，而不仅仅是内存溢出，还有一个原因就是申请到的堆栈意外不足。
在用电高峰期（例如夏季、或晚间的黄金时段），电压的突然不稳定，或许会非常微小，不至于迫使计算机意外重启，但或许会导致VFP系统在通过Windows消息机制向内存体申请堆栈时，得到Windows意外的反馈。
除了说服您的客户使用UPS外，您应该检查用电的负荷情况，比如检查打印机或台灯是否与计算机电源线一起接在一个多功能插座上，应该尽量避免这样，一些老式的打印机，在打印作业时会消耗很大的电流。
热心网友
时间：2024-08-20 17:37
【小聊VFP9与致命错误c0000005】
天哪，太久没来了！以至于好半天才想起如何发表新帖：）
这份帖子主要在讲述“致命错误——C0000005”，它是什么，为什么会出现，何种情况下将出现，以及如何避免之。请根据您的口味选择是否浏览之。
昨夜又见论坛上寻问C0000005的帖子，是关于Visual Foxpro 9.0 版本的，这引起了我的注意。
本以偷懒的态度草草回复之，然而接下来网友的追问使我自知偷懒的后者便是语义表达不到位，便索性连夜写下此主题帖。但仍以简练为主，请大家多担待！
在文章中，若一整段的文字均被括入括号中，则说明它不过是与主题无关的小常识。
c0000005错误发生的诱因主要分为四大类：
1、自由表存储载体的缺陷（主要体现在VCX、VCT，SCX和SCT上）。
2、第三方监控性质的软件。（如：防毒软件在内存即时监控状态下、词霸软件在全屏拾取模式下等）；
3、Visual Foxpro 自身的代码漏洞；
4、硬件因素。
先说第一大类：
同数据表一样，在Visual Foxro 9.0 版本中，自由表也支持了原子事务机制，这并非主要是为了满足客户的需要，而以稳定VFP9自身为主。我们都知道类与表单的代码多以物理形式为自由表的VCX、VCT，SCX和SCT文件格式存储，在IDE设计模式下，代码被VFP后台以独占的、开放式自由表缓冲的模式存取。然而您应该敏感地注意到：自由表是不支持事务机制的（低于9.0版本的Visual Foxro）。也就是说，遇到停电或操作系统异常时，它们同样会面临表头损坏、低级链接错误、记录指针错误偏移的风险。Microsoft Visual Foxpro 开发组没有将VCX、SCX设计为依赖于数据库的数据表的形式，原因不难理解——如果一个表单文件中，包括表单本身在内的任何一个控件都不依赖于用户自定义派生类的话，那么该文件应该可以被独立地拷贝与打开。
如下的常识我们都需要知道：
无论是在设计模式还是在运行模式下，Visual Foxpro的Runtime会随时将客户脚本读取到内存体中，并交由词法分析器、语法分析器和语义分析器来分析、解释、处理这些代码。
（通常情况，在编辑模式下，我们的脚本代码已经被Visual Foxpro词法分析器进行了第一遍的过滤；在编辑完一个prg或表单或类文件后，若按下Ctrl+W组合键将在保存它之前调用语法分析器来试图检查其中的错误（注意“词法”分析器与“语法”分析器的不同），然后程序界面将自动被关闭；而若按下Ctrl+S组合键保存后，再手动退出时，这种情况下将不会调用语法分析程序。）
如果你的脚本保存在自由表形式的SCX、SCT、VCX、VCT文件中，Visual Foxpro会通过表的记录指针提取对应备注文件里的程序脚本（那里或许包含了某些事件或方法的代码），Visual Foxpro会通过调用C语言的sizeof()来判断字节的长度，根据长度提取字节，最后将长度的返回值与实际代码以参数的形式传递给语义分析器来解释执行。然而在一些情况下，会发生sizeof()判断的字节长度与实际的长度不一致的情况。
倘若sizeof()判断的字节长度与实际的长度不一致，将会发生内存的溢出，这个致命错误被Visual Foxpro异常处理器捕获后，将抛出“致命错误－C0000005”的信息。
“致命错误”是字符常量，“c0000005”是一个变量，c0000005不是VFP的错误编码，而是得到Windows消息环所传递过来的错误消息的半加工品。它的原始状态是16进制的0xC0000005，VFP通过相关的转换函数转换成字符串的形式，以便通过界面描述给用户。
那么什么情况下会出现sizeof()判断的字节长度与实际的长度不一致的情况呢？主要有两方面的主导因素。
1、我们前面铺垫过了，VCX、VCT，SCX和SCT文件都是自由表，都有可能在设计时被无意的损坏。
倘若表头被损坏，您会在试图打开它们的时候收到VFP系统的无法打开该表单的信息；但倘若低级链接错误、记录指针错误偏移，您就不会得到任何VFP的提示，因为VFP系统自己也不知道这一点，就像您一样。于是直到程序运行时，才会收到令人惊愕的致命错误信息——语义分析器工作时内存被溢出。
在一些“致命错误－C0000005”的信息框中，您会收到似乎更详细些的信息，指示您程序出错的地方。那通常是包含在SCX、SCT或VCX、VCT里某些行的代码。
千万不要被误导，并不是您的程序代码编写有问题，而是隐藏在标识符之外的、看起来好像是空格、回车的空白段，那里隐藏了低级链接的错误、或Unicode的错位排序（下面马上就会讲述到），用Shift+方向键将整行全选，然后按Delete键删除之，最后老老实实地将原行代码重新书写一遍即可（切记：用Shift+方向键将整行全选，然后将该整行彻底清除）。
2、Unicode。
从Windows98升级过来的VFP程序员似乎都曾有过这样的困惑：为什么Windows2000以上版本的VFP程序会如此的不稳定，以至于频繁出现“致命错误——C0000005”？
您现在上网用的计算机的操作系统是WIN2000或WindowsXP吗？如果是，不妨亲自做这样一个试验：
打开记事本程序，输入“联通”，然后保存后关闭该文本，再重新开打，看到什么了？
是的，当年WIN2000操作系统的流行时，Visual Foxpro开发组并没有彻底改正语义分析器代码的漏洞。
好的，第一大类我就阐述完了。如何避免它呢？
总的应该说很麻烦，有两种途径供您选择：1、修改VCX、SCX表国际代码页的编码，将简体中文编码改为英文编码；
2、我所推荐的方法是尽量用prg。你可能会认为这样做很麻烦，但作为程序员，您应该更加专业一些。您可以备份可视化的表单或类文件，但在程序正式发布前，最好最大限度地转化为prg程序。倘若以后需要修改程序，通过备份的表单或类文件进行可视化编辑，然后再次转化为prg发布之。
顺便告诉您一个小窍门：
在IDE设计模式下，我们或许会突然遇到“致命错误－C0000005”袭击，因为表单是以独占的、开放式自由表缓冲的模式交互的，所以此前未经保存的信息都将被丢失，这您是知道的，通过刚才的讲述，您还知道了这或许会面临表被损坏的风险，从而进入了一个“致命错误－C0000005”潜在引发今后“致命错误－C0000005”故障的恶性循环。
小窍门就是，您千万不要条件反射地去触击那个“确定”按钮！那不过只是Visual Foxpro系统所捕获的异常罢了，它不是真“致命”的，Visual Foxpro系统仍在运转中，也就是说，它还在正常地接收着Windows操作系统不断发送来的消息。这时，请您点开Windows桌面最左下角的“开始”按钮，选择“重新启动计算机”或“关闭计算机”，Windows在试图关闭电脑前，会先检查是否有尚在运行中的应用程序，它会发现一个叫Fox的先生尚未退场，于是便发送清场的消息给Foxpro，Visual Foxpro其实还在正常的运转中，它接收到这条消息后，会调用自身的退出机制试图退出，而自身的退出机制会发现尚有正在编辑的表单，便会发出“需要保存修改吗？”的询问消息，这时候，您选择保存，就可以了！
千万注意了！这段过程大概只有5秒钟的时间！因为为了防止死循环的情况出现，Windows会在等待几秒钟对方不应答的情况下强行终止程序，那时候，就真正退出整个Windows系统了。所以您一定要眼疾手快！
（说到异常处理，便自然地想到了Vfp9新加的异常处理Try机制，事实上倘若不是开发OLE远程服务的DLL，您就没有必要就使用它。因为VFP为您提供的On error或Error事件，其脚本解释程序代码实质上就是C++的异常处理机制，在您熟练地使用VFP错误处理程序时，实际上就等于在使用C++的异常处理程序了。）
第二大类是第三方监控性质的软件。如：防毒软件在内存即时监控状态下、词霸软件在全屏拾取模式下等。其实防毒软件本身并不与VFP产生冲突，但有一个例外，就是内存即时监控（请注意：防毒有许多即时监控，唯有内存即时监控才会与有时候与VFP发生冲突）。
所谓内存即时监控并不是去读取内存条中的数据，谁也没这么大的本事，它的原理就是专门关注于Windows系统目录下的system32子目录中的程序文件在运行中的状态。
我们知道，在Visual Foxpro 8.0 版本以前，其运行时刻文件是安装在system32目录中的；而向最终客户发布你的应用程序时，默认情况下，无论是VFP什么版本，其运行时刻文件均会被拷贝到system32目录中去。
防毒软件的内存即时监控的工作原理是这样的（这是瑞星公司首创的，瑞星软件也是狐友受害最深的）：1、它会在Windows后台运行一个类似于Windows的模拟机（这有点像任天堂游戏模拟机和一些手机模拟机，还有现在时髦的Linux下的Windows模拟机）；2、它运行一个循环，挨个监视system32目录下的exe及dll文件是否被调用；3、倘若被调用，就拷贝一份到瑞星自己创建的隐含、系统目录中去，然后在那个模拟机中运行之，以便模拟其在Windows实际运行中的状态；4、在模拟运行中，看它是否有病毒发作的特征；5、如果有，就查找病毒特征码数据库；6、若在数据库中，找到了对应的特征码，便确定特征码所对应的病毒名称，否则，就按未知名的新病毒处理（这就是为什么有的VFP加密软件会被防毒软件误报病毒）。
由于VFP应用程序与运行时刻DLL库交互的太频繁了，使防毒软件的那个循环程序不断捕捉到VFP运行时刻库在进行新的数据响应，防毒软件便不断地试图拷贝它，以便进行新一轮的模拟。但你知道，无论是DBF还是SCX等等，只要是独占方式打开的（SCX与VCX总是被独占的，而DBF取决于你的设计），就不能被其它的程序所访问。但在Windows操作系统中，防毒软件所调用拷贝程序的系统优先级要高于你的程序的优先级，所以你的VFP程序会最终产生致命错误。
如何避免它呢？你可以简单地关闭防毒软件，但如果让客户也像你这样做的话，就显得太不专业了！
聪明的你恐怕现在已经想到了：只要在发布你的应用程序时，将那些运行时刻库放到应用程序目录下就可以了！
同样，词霸软件本身也不会与你的程序发生冲动，只是在全屏取词的模式下才会如此。不过你的用户几乎不会遇到，因为你的程序几乎不会让他们在程序界面状态下直接打开某个数据表——仅在词霸的全屏取词程序试图通过独占模式下的数据表的窗口句柄，来访问里面的文本属性时，才会与其独占模式发生冲突。
第三大类是Visual Foxpro 自身的代码漏洞。比如VFP6.0版本的Textbox控件等等。现在版本的VFP，这样的错误少多了，我们的话题就不再展开。
第四大类是硬件因素。
有些细节问题是最不被人所注意的。但其足以铸成大过。
“致命错误C0000005”是内存泄漏的症状，而不仅仅是内存溢出，还有一个原因就是申请到的堆栈意外不足。
在用电高峰期（例如夏季、或晚间的黄金时段），电压的突然不稳定，或许会非常微小，不至于迫使计算机意外重启，但或许会导致VFP系统在通过Windows消息机制向内存体申请堆栈时，得到Windows意外的反馈。
除了说服您的客户使用UPS外，您应该检查用电的负荷情况，比如检查打印机或台灯是否与计算机电源线一起接在一个多功能插座上，应该尽量避免这样，一些老式的打印机，在打印作业时会消耗很大的电流。
