当出现XX内存不能为写的时候
这种错误可以用try 和catch 处理吗?
还是只要出现这种错误WINDOWS就会强行关闭程序?
出现这种错误程序还有救吗?
这种错误可以用try 和catch 处理吗?
还是只要出现这种错误WINDOWS就会强行关闭程序?
出现这种错误程序还有救吗?
解决方案 »
- 关于bmp文件的问题
- CDATAGRID 控件 数据不显示
- 请问如何将一个自定义的数据类型存入数据库?
- 绘制快速走动的仪表时,怎样降低CPU占用率??有好方法的进来讨论一下
- 怎么样打开其它文件
- 请问为什么我用VC6 编译dll后, debug目录并没有 lib 文件的?谢谢!具体步骤如下。
- 安装vs6的sp6后出现的问题。
- 求希尔排序的源码,急!!!
- 技术难题:两类互为成员变量
- 请帮下,谢谢:我从ListCtrl的某一单元格中取内容,结果只返回首个字符(返回的是单个字符,不是字符串),请问下这个是为什么,怎么解决了?谢谢!
- 请教DeviceIoControl函数的用法及Ring3级主程序与VXD通信问题;
- InstallShield的简单问题
我的程序中有几处DOUBLE--》LONG的转换会引起这种问题吗?
DEBUG模式下,跑出错时不要急的关闭,看看CALL STACK调用函数栈,看看是在哪个函数处出错了!
When exceptions occur, the system can trap them, and use the trap handler to handle them.
First, simple exceptions are resolved by trap handler,
other exceptions are serviced by exception dispatcher.
The exception dispatcher's job is to find an exception handler that can dispose of the exception.The kernel traps and handles some of these exceptions transparently to user programs. For example, encountering a breakpoint while executing a program being debugged generates an exception, which the kernel handles by calling the debugger. The kernel handles certain other exceptions by returning an unsuccessful status code to the caller.A few exceptions are allowed to filter back, untouched, to user mode. For example, a memory access violation or an arithmetic overflow generates an exception that the operating system doesn't handle. An environment subsystem can establish frame-based exception handlers to deal with these exceptions. The term frame-based refers to an exception handler's association with a particular procedure activation. When a procedure is invoked, a stack frame representing that activation of the procedure is pushed onto the stack. A stack frame can have one or more exception handlers associated with it, each of which protects a particular block of code in the source program. When an exception occurs, the kernel searches for an exception handler associated with the current stack frame. If none exists, the kernel searches for an exception handler associated with the previous stack frame, and so on, until it finds a frame-based exception handler. If no exception handler is found, the kernel calls its own default exception handlers.When an exception occurs, whether it is explicitly raised by software or implicitly raised by hardware, a chain of events begins in the kernel. The CPU hardware transfers control to the kernel trap handler, which creates a trap frame (as it does when an interrupt occurs). The trap frame allows the system to resume where it left off if the exception is resolved. The trap handler also creates an exception record that contains the reason for the exception and other pertinent information.If the exception occurred in kernel mode, the exception dispatcher simply calls a routine to locate a frame-based exception handler that will handle the exception. Because unhandled kernel-mode exceptions are considered fatal operating system errors, you can assume that the dispatcher always finds an exception handler.If the exception occurred in user mode, the exception dispatcher does something more elaborate. the Win32 subsystem has a debugger port and an exception port to receive notification of user-mode exceptions in Win32 processes. The kernel uses these in its default exception handlingDebugger breakpoints are common sources of exceptions. Therefore, the first action the exception dispatcher takes is to see whether the process that incurred the exception has an associated debugger process. If so, it sends the first-chance debug message (via an LPC port) to the debugger port associated with the process that incurred the exception. (The message is sent to the session manager process, which then dispatches it to the appropriate debugger process.)If the process has no debugger process attached, or if the debugger doesn't handle the exception, the exception dispatcher switches into user mode and calls a routine to find a frame-based exception handler. If none is found, or if none handles the exception, the exception dispatcher switches back into kernel mode and calls the debugger again to allow the user to do more debugging. (This is called the second-chance notification.)
http://dev.csdn.net/article/26/26348.shtm