The effect of the file version of the MFC library on the program: unhandled exception in ***. EXE (mfco42d. dll) 0xc00000005: access violation. However, in most cases, it still performs memory operations.

In general, the developed MFC program generally uses the Library about MFC in VC, in the form. lib and corresponding. DLL, in the project settings, in project-> setting-> General, there is "using
MFC in a static library "or" Using MFC in a shared
DLL ", in general development, if the project is just a separate program, we generally use" Using MFC in a static
Libraries can only be used when they are put together, but it is troublesome and the overall program will be relatively large.

All projects in the company are classified and put together. If every local .exe uses "Using MFC in a static
Library ", in this case, the entire .exe set will be much larger, so the general use of" Using MFC in a shared
DLL "option, in this case, when the entire migration to the client, you have to copy the mfc dll compiled and used during development to the project bin for public use. MFC
DLL is generally mfc42d. dll, mfcans32.dll, mfcd42d. dll, mfcn42d. dll, mfco42d. dll.

Recently, during development, I encountered a very strange problem, that is, when the coledatetime method is used during debugging and execution of my program, errors will occur. For example, "unhandled"
Exception in ntautoscript.exe (mfco42d. dll) 0xc00000005: Access
Violation ", coledatetime is the MFC class, and its debugging is also exported from the DLL. After a Google trip on the internet, I found that it was impossible to pass null pointers, this project is okay on other development machines. Once I rebuild it, there will be a problem. It must be a problem with my machine or a problem with the development environment, but now the problem lies in the DLL of MFC, which is not a problem of my program. It must be that the debugging fails ..

After careful comparison, I finally found the problem. Generally, when compiling our own project, if we select "Using MFC in a static
Library ", VC will use (default path)" C:/program files/Microsoft Visual
Studio/vc98/mfc/lib ". Lib under the path is compiled, and the corresponding MFC under the path" C:/Windows/system32 "is used for the link
Dllimplements the link. At the end, the .exe generated in our project only has a dynamic link pointer and no execution body. I refer to the API or class about MFC. The MFC under "C:/Windows/system32" is
The DLL is loaded into the memory and then located in the mfc dll according to the API pointer in our program for execution.

But why is there an exception? The problem is that the dll version is inconsistent. The company's project bin is developed using the program MFC
DLL. Let me give you an example of an error, mfco42d. the dll version is 6.0.8168.0. After installing the VC on my current computer, I can check "C:/Windows/system32" to find mfco42d. the dll version is 6.0.9782.0 because. DLL and. lib is used in combination, so if I use version 6.0.9782.0 during project compilation. lib. the dll must also be version 6.0.9782.0, so now I use version 6.0.9782.0 during compilation, which is a little higher. Then, when I run the program, I search for the DLL from the program root directory, so the old version 6.0.8168.0 is used, so the pointer error is always prompted during execution ..

The solution is to ask another colleague's machine to use. Lib above version 6.0.8168.0, which is the path "C:/program ".
Files/Microsoft Visual
Studio/vc98/mfc/lib ", replace it with the old one. The program uses the old. dll above the company bin.

In fact, we often call VC 6.0. In fact, it also has many versions, such as VC 6.0 SP1, VC 6.0 SP2,... VC 6.0
SP6, what other Personal Edition, Enterprise Edition, because of the upgrade, so the MFC. lib and. the dll will also be changed, so the VC versions used by your team should be the same when you open the SDK. Otherwise, you may need to pay attention to the problems solved above ..

It is best to set "C:/program files/Microsoft Visual
Studio/vc98/mfc/lib ", extract it and put it into the company project. The development team should use this lib directory for compilation, and it will be OK, in this way, the team members can use the VC version...

 

PS: 0xc0000005 error indicates that the program has unauthorized access to the memory. Generally, the pointer or handle is incorrect. For example, the pointer is not initialized. Check how your controls are associated, and debug the class constructor.