Part of the problem is the poorly written VB IDE/compiler. It is normal for two sequential builds, made one immediately after the other, to be significantly different. part of these differences is the obvious one of date-and-time. But, for the most part, the differences are just the garbage that VB fails to clean up. While the significant code portions are of course correct, the unused "don't care" portions of memory are also just dumped into the exe.

A helpful procedure, after you have finalized your code, is to shut down your machine, re-boot, and go immediately into VB without any other progs running. Then, compile. In this manner, you will get the cleanest exe, as the garbage has not yet been put into memory, so it doesn't make it's way into your exe. Note that this method just gives you the "cleanest" exe, not a "clean" exe.

Since this is not a PE file problem per se, a better way to analyze a VB exe specifically is to attack it in the manner it is created; that is, not as a PE file, but as a VB file. Otherwise, you will spend a lot of time analyzing significant parts of the exe that don't mean anything. Of course, you need the PE info to find the VB info IN the exe.

Sarge