Intense frustration

[UtahJ]

Greetings,

I have a program that uses the FindFirstFile API.
It worked perfectly for months, but recently I started
getting an application error crash when running the compiled
version of the program. It runs fine in debug mode.

It is actually crashing on the FileCopy line below:

FileCopy sINIPath & sOrderNumber & "\" & typFileData.cFileName, flstCadFile.Path & "\" & typFileData.cFileName

I'm guessing something is happening to the typFileData
information that is populated by FindFirstFile, but the data
looks fine.

I have not changed the code at all, so this is very frustrating.
I'm running VB6 Enterprise on NT4.

Does anyone have any ideas as to what could be happening?


Here are my module declarations:

Type FILETIME
dwLowDateTime As Long
dwHighDateTime As Long
End Type
Type WIN32_FIND_DATA
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * 50
cAlternate As String * 14
End Type
Public Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long

Thank you!

[Nucleus]

Use a watch on the variables:

typFileData.cFileName, flstCadFile.Path, typFileData.cFileName

[jim mcnamara]

Under NT (really Win 9X but it's more forgiving) you MUST execute FindClose to deallocate the file context, or the next time you call FindFirstFile, then do something it will crash the thread.

Check to be sure you FindClose absolutely every time.

[UtahJ]

I did a watch, the data is valid. Like I said, it runs fine in debug mode, but pukes when I run the executable.

I do a FindClose after the FileCopy. I'll try moving it before
the FileCopy to see what happens. Thanks.

This is very unusual, escpecially since it just started out of the blue.

Thanks for the reponses.

[jim mcnamara]

Oooo. I didn't get part of what your problem was. May not be code.

Welcome to dll Hell.

Some other OS or software component was added or updated. Betcha. This crud-ola happens everytime we upgrade out FirstLogic product. They insist on overwriting dll's with older versions.
Go into:
Startup > Accessories > System Information > Tools > Version Conflict Manager

Chances are you'll find older dll's as the current version. Restore them so the newer version is in use. This doesn't always work, but it's the place to start.

[UtahJ]

"Some other OS or software component was added or updated. Betcha. This crud-ola happens everytime we upgrade out FirstLogic product. They insist on overwriting dll's with older versions.
Go into:
Startup > Accessories > System Information > Tools > Version Conflict Manager"



Jim,

Yeah... I have to agree with you.

Unfortunately, I'm on NT 4.0, and I don't have the Version Conflict
Manager.

Lucky for me, I'm the only person in the department who runs this
particular program, so I have just been running it in debug mode.

Sure is a pain in the *** though.

Thanks again.

[UtahJ]

Hey Jim,

Could you explain why the program runs fine in VB, but
crashes when run as an exe? Does VB somehow protect
the program from DLL conflicts?