当出现XX内存不能为写的时候
这种错误可以用try 和catch  处理吗? 
还是只要出现这种错误WINDOWS就会强行关闭程序?
出现这种错误程序还有救吗?

解决方案 »

  1.   

    应该还有救.你去CSDN的FAQ里面找找.我记得有这么一个贴子可以返查找到是那一些出的问题
      

  2.   

    请问是不是因为数组越界引起的吗 
    我的程序中有几处DOUBLE--》LONG的转换会引起这种问题吗?
      

  3.   

    看看对指针进行操作时是不是都判断是否为空了,如果操作空指针会出现内存错误的!
    DEBUG模式下,跑出错时不要急的关闭,看看CALL STACK调用函数栈,看看是在哪个函数处出错了!
      

  4.   

    I think you should know the mechanism the system use to handle exception.
    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.)
      

  5.   

    could you speak in chinese?
      

  6.   

    refer to
    http://dev.csdn.net/article/26/26348.shtm