How to solve xxx.exe (kernel32.dll): 0xc0000005: access violation.

First-chance exception in xxxx.exe (kernel32.dll): 0xc0000005: access violation.

Client code bug.

In the past, this bug was encountered because there were too many engineering source codes and they could not be found one by one, because each person was responsible for different modules and it was difficult to locate them,

It may be a problem with your own code, or the underlying code may be wrong. However, such errors may cause random errors.

This kind of program crashes, often with no prompt to exit, it is difficult to locate.

This bug occurs when the program exits. It uses a very stupid method to solve this bug at the beginning.

That is, every class destructor prints information. This method is stupid but practical.

Locate the problem. The Code calls imagelist_destroy (m_himagelist) during the analysis,

The reason is also very simple. The m_himagelist handle is not initialized. It can be seen that initialization variables are a good habit!

Fixed the above problem. The program in win7 did not appear (kernel32.dll): 0xc0000005: access violation.

However, there are still many such errors on XP machines, and they are also tangled. This bug has never been detected during dinner, so it cannot be located.

Get up early in the morning, head awake, bind the program with windbg, and locate the problem in a few minutes-or the image list.

Cause 1:The global image list is passed into a class and is analyzed twice. A specific class is destructed once, and a global data class is destructed once.

Here is another lesson: Global shared data is carefully modified by some reference modules.

Cause 2:Windbg prints the following information.

Comctl32! Cimagelistbase: isvalid + 0x12
Comctl32! Himagelist_queryinterface + 0x2c
Comctl32! Imagelist_getbkcolor + 0x1b
Comctl32! TV _selectitem + 0x22
Comctl32! TV _deleteitemrecurse + 0x156
Comctl32! TV _deleteitem + 0xae
Comctl32! TV _wndproc + 0x5d4
USER32! Internalcallwinproc + 0x28
USER32! Usercallwinproccheckwow + 0x150
USER32! Callwindowprocaorw + 0x98
USER32! Callwindowprocw + 0x1b
XXX! ATL: cwindowimplbaset <sx_treeviewbase, ATL: cwintraits <1442840576,0 >:: defwindowprocw + 0x31
0012bb34 77d18734 sxim! ATL: cwindowimplbaset <sx_treeviewbase, ATL: cwintraits <1442840576,0 >:: windowproc + 0x101
USER32! Internalcallwinproc + 0x28
USER32! Usercallwinproccheckwow + 0x150
USER32! Sendmessageworker + 0x4a5
USER32! Sendmessagew + 0x7f
XXX! Wtl: ctreeviewctrlt <ATL: cwindow >:: deleteitem + 0x74

Although convenient, VC 6.0 is a very backward tool. Sigh ~

It is easy to confirm the problem from the printed information, comctl32! Cimagelistbase: isvalid + 0x12 -- or the image list.

Cause analysis:Global data is called in ondestroy in the upper-level window. All image resources such as tree and list are released.

In this way, a problem occurs when the subwindow needs to release the data deleteitem. Therefore, global data must be stored in the destructor.

The problem has been solved and many detours have taken place. Now we are in a good mood. The weather is so good today ............