Help: VB6 app gives error 54

[RussM]

I am helping a non-technical friend resolve a problem with a VB application. The original programmer is unable to be contacted. This tiny 40kb program reads a setup.txt file, establishes a telnet into a device, issues a data dump command, then takes that data, parses and reformats it, then pushes it out to a MySQL db on a linux box. The program is normally repeatedly executed at 5 minute intervals using Scheduled Tasks. It ran fine for nearly 2 years, then a few months ago it quit working and started throwing the Run-time Error 54: Bad File Mode. I haven't done any VB work in years, but I do recall that this is typically a programming error. The program also creates a log file; the log entry after each attempted run is "Error Occured: Input past end of file."

However, the program hasn't changed, nor did the setup.txt configuration file.

That leaves two possibilities as I see it...

- the data obtained from the device is formatted differently.
- something on the XP PC has changed, such as a dependent DLL.

The firmware on the device has been upgraded several times since the program was first used, but my friend says that the most recent firmware update was done several months before this system broke. Just to be sure, I down-rev'd the device firmware several releases, and the error still persists. I also did a comparison of the data dump output, and it is identical between old and firmwares. So, I doubt that the device itself is part of the problem. This leaves the PC & OS as my best guess, but I really don't want to go on a wild goose chase trying to find out what piece of Windows software (if any) is responsible.

I re-installed the VB6 run-time package, but that didn't help. The guy says he's never installed any run-time updates either.

Any thoughts?

[deathfxu]

It is clear from the error message that the problem is either occurring during the "reformatting" step, or just after, during the "sending data to the linux box" step.

- the data obtained from the device is formatted differently.
- something on the XP PC has changed, such as a dependent DLL.

I think your two conclusions are right.

The second option can be addressed, but assuming you don't know what changes have been done to the computer (which it sounds like the case is), it would probably at least require a complete reinstall of all dependent dlls. Which i'm sure I don't have to tell you, could be quite lengthy (telnet, msvbvm60.dll, any mysql dlls, etc), and that might not even fix it.

So in hopes that it is the first option, I know you said you checked the data dump outputs, but would it be possible for you to upload here a current data dump output, and one from before when it was known to be working?

It could be something as mundane as a space character at the end of the file, and a fresh pair of eyes might see something you didn't.

[deathfxu]

I had another thought.

It might also be worth it to try downloading a Visual Basic decompiler to try to break the program back into code. Keep in mind if you have never done this before that what it decompiles into may be very rough, but it may give you some insight.

I would definitely look deeper into the data dump outputs first though.

[RussM]

After my OP, I monitored communications with WireShark (packet sniffer), and the problematic app never even makes it to the point of establishing the telnet session - there was no network activity. The XP firewall does have an exception for the program to permit telnet and the MySQL comms; just to be sure, I disable Windows Firewall... no help. I probably should have done this sooner, and saved myself a whole bunch of time playing with the firmware versions

I've effectively eliminated the data itself as the culprit, since the app never even gets any data before it throws the error.

There is a MySQL ODBC connector used... it's still the same version & build as originally installed, and removed and I reinstalled that too, so I think I can eliminate that component. I forgot to mention that previously

I'll search for a decompiler... maybe it will help me at least understand the program flow better. Can you recommend a free one?

[wes4dbt]

Most likely the data file format has changed. Try and compare the current file format with an old file that ran correctly. They should be archived somewhere.

BTW - There is no VB decompiler that produces readable code.

[RussM]

Most likely the data file format has changed. Try and compare the current file format with an old file that ran correctly. They should be archived somewhere.

As the app never even progresses to the point of establishing the telnet connection, the data content or format is no longer a possible cause.

The setup.txt file has not changed - the last modified date is over a year before the problem began.

[deathfxu]

So if I am understanding right, either a program dependency has changed or the problem is on the end of whoever telnet connects to. Good luck. =/

Btw, VB decompilers do exist, they just don't decompile into VB. You get to learn a new language to delve into that fun (see my sig).

[deathfxu]

I found a free program dependency checker. I downloaded it, virus scanned it, and tested it out for ya. It works great.

Check my sig for the link.

[RussM]

As the app never even progresses to the point of establishing the telnet connection, the data content or format is no longer a possible cause.

I should clarify: the app never even progresses to the point of attempting the telnet connection.

Thanks, DeathFXU. I tried a decompiler and nearly screamed in agony when I saw the output ... I haven't touched assembly in 25 years, and then it was for 65C02/65C816 and MC680x0. Can you tell I'm a dinosaur when it comes to programing?

Will try that dependency walker later today...

[deathfxu]

Yeah, I started programming in old DOS Basic, so I hear ya. I am learning assembly at the moment. Still seems like greek sometimes though. =P

If the app never even attempts the telnet connection, it definitely smells of a dependency problem. I wish there was an easier way, sadly, Microsuck hates us all.