Troubleshooting Suspected Project Corruption

Xtreme Computing Has Closed
Thank you for your business and interest 1996 - 2007.
Site is, maintained for archival purposes. Links, e-mails and information may be broken, invalid or otherwise obsolete.

Troubleshooting Suspected Project Corruption

Project corruption was extremely common in VB3, and while it has been less ubiquitous in subsequent versions, corruption still can occur. A file within a VB project can become corrupt for any of the same reasons ANY file can become corrupt. As we all know, stuff happens.

It is seldom possible to know beyond a doubt whether corruption is the source of a problem. That’s why this document is titled using the word "suspected." You should always rule out more obvious or easier to troubleshoot possibilities first. An error or problem that has you saying, "that’s bizarre!" and turning up nothing in the Microsoft KB is an above average scenario for suspecting corruption. A good scenario is when a project runs fine in the IDE but either won’t compile, or behaves strangely as an executable.

The Bad Old Days

In the days of VB3 there were four types of files to worry about, but with a twist. You could have MAK, FRM, FRX and BAS files associated with a project. The MAK is strictly text, and is the main project file. BAS modules are also strictly text. In VB3 an FRM could be either binary or text, with binary as the default. If an FRM is text, then an FRX will be created as needed to store binary information that can’t be represented in a text-based file. That can include things like picture and icon properties, and sometimes settings written there by controls.

Corruption is vastly more likely to occur in binary files, so the location of the corruption is most often an FRX. Binary was eliminated as an option for saving forms when VB4 arrived on the scene because having binary FRM files compounded the problem in VB3! In that version it was relatively common to have corruption that prevented a form file from loading. If it was binary and was toast, the form had to be rebuilt from scratch.

File Types

In VB4, VB5 and VB6 the following files are among those that can be associated with various types of projects.

VBG	Project Group	Text	VB5/6 only
VBP or MAK	Project File	Text
FRM	Form File	Text
FRX	Form Stash	Binary
BAS	Code Module	Text
CLS	Class Module	Text
RES	Resource File	Binary
PAG	Property Page	Text	VB5/6 only
PGX	Property Page Stash	Binary	VB5/6 only
CTL	User Control	Text	VB5/6 only
CTX	User Control Stash	Binary	VB5/6 only
DOB	User Document	Text	VB5/6 only
DOX	User Document Stash	Binary	VB5/6 only

The most common are form, project, module, class and FRX files, so those are the ones discussed below. Extrapolate as needed based on the type of files involved.

What to Try
(Assuming a standard project; extrapolate as needed.)

Project corruption is not that difficult to troubleshoot, though people are sometimes reluctant about it. It can be best viewed as a set of steps starting from least drastic; holding out hope that the easier steps will work, as they usually do. The items listed below are a variety of steps from less to more drastic and involved. Favor the simpler things unless they fail.

Even though the project is suspected of being corrupt, you should always make a backup copy of all project files before starting to dissect it.

1 – Rename FRX files.

This rules out the most likely source of corruption and is simple. Recovering will involve rebuilding any affected properties. If a specific form seems to be the source of the problem, it cannot hurt to start with only that FRX. Conversely, you can always test by process of elimination or re-inclusion for the satisfaction of identifying exactly the corrupt file(s) and to reduce the amount of resetting of properties needed in a large project.

2 – Remove forms from the project until it works.

A different way of identifying if a particular form or FRX is associated with the problem.

3 – Add forms to a new project until it breaks.

The inverse of item 2. Both are good troubleshooting steps in general, even for scoping out problems that aren’t corruption.

4 – Add the forms, modules and classes from the afflicted project into a new project.

Set the appropriate project properties and test. This rules out the VBP (or MAK as some projects might still be named).

5 – Copy the text of the file to a new Notepad file and save.

This applies to any of the text format files. For instance, open an FRM in Notepad, copy the contents, start a new Notepad file, and paste. Rename the original FRM and save the new file with the same name. Repeat the process with all the files in the project, and in concert with renaming FRX files, that gives you a fairly clean start.

6 – Another way of essentially rebuilding the project with shortcut methods is to perform the following steps:

A - Open the troubled project in VB (if it will open).

B - Start a new project in VB.

C - Add the appropriate blank forms and modules to the new project.

D – Either go to each form in turn in the suspect project, selecting all the controls on it and copying them, then paste the controls to each corresponding form, OR redraw the appropriate controls on each new form. Redrawing the controls is more certain to safely shed the corruption and is really the preferred method. Copying controls by some accounts may provoke corruption rather than shedding it.

F – Set the properties of each new form as needed.

G – Using full module view, select all code in each form and module in turn, copy and paste into the corresponding target files.

This can be applied to an entire project or a specific file within a project. It is about as close as you can get to rebuilding the file(s) from scratch without the effort.

7 – If the problem can be isolated to a single file and none of the rebuild methods work for that file, it will have to be rebuilt from scratch.

8 – If you are using Visual Source Safe or some other source code control program, backtracking to an earlier "build" of the project and rebuilding from that point may shed the corruption.

Contents of this page copyright 1999 by Marshall Ellis
Published by XTreme Computing with permission of the author.
Microsoft product support personnel are authorized to distribute this document if they wish.
This document and the advice contained herein are distributed "AS IS" to be used at your own discretion and risk. No support is granted or implied by the author, XTreme Computing, or Microsoft, but feel free to write if you would like to provide feedback.

Comments? Write: Webmaster@XTremeComp.com
Last Updated August 29, 2001

All contents copyright XTreme Computing unless noted otherwise.