一个关于Beep()函数的怪现象

[ahzhuo]

在VC6种调试程序时，每当调用 ::Beep() 函数的时候，VC6的调试窗口都会输出一条异常信息：

First-chance exception in App.exe (KERNEL32.DLL): 0x000006BA: (no name).

我未做任何异常处理，但是程序不会出现问题，不论是Debug版还是Release版。可是我不知道会不会存在什么隐患，故发此帖，希望大家能帮我来验证一下是不是只有我的机器上才是这样的？

测试方法：新建一个名为TestBeep的基于对话框的MFC工程，一切都用缺省设置。然后添加OnOK()响应函数，在OnOK()函数中添加一句 ::Beep(500, 500); 同时注释掉 CDialog::OnOK(); 这一行。最后编译Debug版运行，看看是不是每点击一次“确定”按钮，VC6的调试窗口都会输出那条异常信息？

PS：我的机器环境：P4 3.0 GHz, 512 MB RAM, Windows XP Professional SP2 中文版, VC6 + SP5 + Processor Pack + Visual Assist 6.0

[syy64]

为什么要注释掉 CDialog::OnOK();？

[ahzhuo]

这样可以多点击几次嘛，看看是不是每次都有那条异常信息。

[一个傻冒]

在VC中调试程序时，Output窗口有时会出现“First-chance exception in xxx.exe...”这样的信息。一般来说，这是由于程序中发生了异常，被VC捕获而产生的输出。

在调试器中运行程序时，如果程序产生异常，调试器会首先获得通知（即First-chance exception），而后此异常由产生它的程序负责捕获。如果程序没有捕获此异常，那么调试器会再次被通知（即Second-chance exception，Last-chance exception），并结束程序。

通常见到的“First-chance exception”一般是“0xC0000005: Access Violation”，“0xC00000FD: Stack Overflow”等，这些都说明程序中有缺陷，需要修正。

但是也有一些属于正常的情况，例如“First-chance exception in xxx.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception”。Windows 操作系统中广泛使用了结构化异常（SEH）来处理特殊情况，许多和底层打交道的API都靠SEH来处理可能发生的意外。并且，这些API中都有捕获SEH的代码，产生的异常不会对程序造成影响。但是由于上面提到的“First-chance exception，Second-chance exception”机制，VC仍然会有输出，但是我们完全可以忽略。如果你实在不喜欢这些输出信息，那你就必须禁用对特定异常的“First-chance exception”捕获。

[ahzhuo]

楼上的说得我放心多了，谢谢！

不过我还是想知道，这::Beep()引起的这条异常信息，是否是我的一个个案？

[ahzhuo]

没有人能帮忙试一下么？希望大家能帮帮我这个小忙，我在这里先谢谢大家了！

[一条晚起的虫]

没有你说的现象

[一个傻冒]

我试了.没有你说的异常.

[ahzhuo]

啊~~~难道我的情况真的是个案？这是怎么回事？真担心有潜在的问题，我程序里有好多处用到了Beep()函数，难道是我的VC6开发环境有问题？怎么办呀？

[一个傻冒]

The exception code 0x000006ba means RPC_S_SERVER_UNAVAILABLE. This error most likely means that the server process has gone away.

[ahzhuo]

对了，我好像关闭了 RPC 服务，这个跟 Beep() 函数有啥关系呀？

[ahzhuo]

哦，我检查了一下 Remote Procedure Call (RPC) 服务没有关，是自动的；Remote Procedure Call (RPC) Locator 服务是手动的。似乎不是跟这些服务有关吧？

[youngwolf]

新建一个MFC程序，什么程序都不写，在debug下也是错误一大堆，这很正常啊，如果用BoundsChecker来查看内存泄漏，还会有一堆内存泄漏，查看源代码的时候，你会发现那些源代码还是MFC的代码，微软写的。

[DrSmart]

晕，根据经验，和系统服务有关，有时候把server服务禁用，在debug中的open dialog就有类似的，不过是no name的会被SEH系统自己处理，可以用kd调试器dump看看系统底层出现了什么问题