Table 2 - Currently Allocated Memory Addresses
It is seen that 00730079 is not included as a valid address and thus the memory access violation occurs.
By examining the processor registers, as shown in Table 3, the EIP or instruction pointer is set to the value of MSVCR71.7C3417E1. MSVCR71 is one of the external dynamic link libraries (DLL) loaded by messenger at run time, and is a common DLL supplied by Microsoft. Through examination of the source assembly, it is found that this instructions lies within the strlen function and the instruction that caused the fault is MOV AL, BYTE PTR DS:[ECX]. This instruction moves the contents of the address located at ECX into the lower part of the EAX. ECX is unreadable and thus the access violation.
Table 3 - Registers
After much experimentation it was found that a single shared files packet would not cause a crash. Even if multiple packets were sent, if enough time has elapsed between the packets Messenger will not crash. Only if a second packet is received by Messenger before processing is complete on the first packet will the access violation occur. This leads me to conclude that the packet being received by Messenger is not so much of the problem as timing issues within Messenger. By adding break points to the program, it is found that considerable processing is performed between certain types of packets. One such packet is the P2P file transfer packet used in the shared files boot. Several registry accesses are performed and in total over 10,000 operations are performed before this type of packet is fully processed. Even with lighting fast speeds of current processors, this lag gives plenty of time for a second packet to be received by a relatively slow network connection.
This theory is further supported by studying other boot code. Although different packets are used, every boot needs to send multiple packets in rapid succession and all boots result in an access violation at address 00730079.