[RESOLVED] Error 5 and Error 52 Problem

I'm not sure whether to post this here or under Deployment, but I thought best to start here. A few users in Asia are having trouble after installing one of my VB6 Apps. I cannot replicate these errors here on any Vista or XP machine that I have.

During invocation, the program reads and decrypts files from both the AppData directory and the App directory. On occasion, users report Error 5 (Illegal Function Call) and Error 52 (Bad File Name or Number). Users have been instructed to be sure that the Windows language setting is set to English. Regardless, the error occurs. Here's a typical report:

"After I install the CD ROM, it first says that "an unrecoverable error 5 has occurred"; then I change my language settings and yet it says that "an unrecoverable error 52 has occurred."

These are error traps that I set in the program because it cannot continue in either case. Any ideas why this is occurring in Asia and not here? The software was installed and tested thoroughly on both XP and Vista.

5 stands for "Invalid procedure call" and 52 - for "Bad file name or number".

Quote:

---

Invalid procedure call or argument (Error 5)


Some part of the call can't be completed. This error has the following causes and solutions:

Anargument probably exceeds the range of permitted values. For example, the Sin function can only accept values within a certain range. Positive arguments less than 2,147,483,648 are accepted, while 2,147,483,648 generates this error.
Check the ranges permitted for arguments.

This error can also occur if an attempt is made to call aprocedure that isn't valid on the current platform. For example, some procedures may only be valid for Microsoft Windows, or for the Macintosh, and so on.
Check platform-specific information about the procedure.


Bad file name or number (Error 52)


An error occurred trying to access the specified file. This error has the following causes and solutions:

A statement refers to a file with afile number or file name that is:
Not specified in the Open statement or was specified in an Open statement, but has since been closed.
Specify the file name in an Open statement. Note that if you invoked the Close statement withoutarguments, you may have inadvertently closed all currently open files, invalidating all file numbers.

Out of the range of file numbers (1 – 511).
If your code is generating file numbers algorithmically, make sure the numbers are valid.

There is an invalid name or number.
File names must conform to operating system conventions as well as Basic file-naming conventions. In Microsoft Windows, use the following conventions for naming files and directories:

The name of a file or directory can have two parts: a name and an optional extension. The two parts are separated by a period, for example, myfile.new.


The name can contain up to 255 characters.


The name must start with either a letter or number. It can contain any uppercase or lowercase characters (file names aren't case-sensitive) except the following characters: quotation mark ("), apostrophe ('), slash (/), backslash (\), colon (:), and vertical bar (|).


The name can contain spaces.


The following names are reserved and can't be used for files or directories: CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, and NUL. For example, if you try to name a file PRN in an Open statement, the default printer will simply become the destination for Print # and Write # statements directed to the file number specified in the Open statement.


The following are examples of valid Microsoft Windows file names:
LETTER.DOC
My Memo.Txt
BUDGET.92
12345678.901
Second Try.Rpt

---

Quote:

---

Originally Posted by Code Doc

I'm not sure whether to post this here or under Deployment, but I thought best to start here. A few users in Asia are having trouble after installing one of my VB6 Apps. I cannot replicate these errors here on any Vista or XP machine that I have.

During invocation, the program reads and decrypts files from both the AppData directory and the App directory. On occasion, users report Error 5 (Illegal Function Call) and Error 52 (Bad File Name or Number). Users have been instructed to be sure that the Windows language setting is set to English. Regardless, the error occurs. Here's a typical report:

"After I install the CD ROM, it first says that "an unrecoverable error 5 has occurred"; then I change my language settings and yet it says that "an unrecoverable error 52 has occurred."

These are error traps that I set in the program because it cannot continue in either case. Any ideas why this is occurring in Asia and not here? The software was installed and tested thoroughly on both XP and Vista.

---

If those are the exact messages then it's strange because there are no hits when those exact phrases are Googled.

Reading between the lines for error 5 that Rhino posted: "This error can also occur if an attempt is made to call a procedure that isn't valid on the current platform. For example, some procedures may only be valid for Microsoft Windows, or for the Macintosh, and so on."

One has to wonder if the Chinese machines have an OS platform that is triggering this? Just a WAG. :rolleyes:

The code is rather straight forward, nothing fancy. I open the files in binary, read in the entire string and decrypt it. All files remain open until they have been read and then all are closed prior to the unloading the invocation form. As I said before, this code has never failed on USA machines. During the decryption process, I swap millions of ASCII character values, thus reversing the encryption.

The only reason I request the English language setting is that one of the controls deperately needs it and will produce an error 380 (Invalid Property Value) if the Windows language is set to Chinese.

Then there is another possibility. Is it possible that the installation program installed a corrupt file to the hard drive from the CD ROM without detecting it? :ehh:

Could those messages be generated from some 3rd party software or control?

It's interesting that they mentioned the CD-ROM - are the trying to run it from the CD-ROM and are you accessing APP.Path to write at that point in the code?

Quote:

---

Originally Posted by technorobbo

It's interesting that they mentioned the CD-ROM - are the trying to run it from the CD-ROM and are you accessing APP.Path to write at that point in the code?

---

No, the software cannot run from the CD ROM. It has to be installed on the hard drive. When that is complete, several files that get revised during usage are loaded onto the AppData directory and those that I simply read will remain on the App directory with the executable. Then when the software is uninstalled, all the files are wiped clean.

Quote:

---

Originally Posted by MartinLiss

Could those messages be generated from some 3rd party software or control?

---

Well, from what I have gathered, these errors occur before the major 3rd party software control that I use (TxText) is loaded. The form creating the error is the invocation form, and all it has on it is a progress bar, a command button, three labels, and an image box. It takes about 2 to 4 seconds, depending on clock speed, to read in the files, decrypt, and advance to the Navigation form.

You may already be aware of their support forum.

Yes, I have dealt with that group before, but I believe this is not their control's problem. Here is a snippet of code where I think the error 5 occurs on the Chinese machines:

Code:

---

Dim ReverseData As String, AllText As String, TestPreamble As String
Dim TestFile1 As String, TestFile2 As String
Dim ZZ As Integer, I As Long, J As Long, Start As Long, EndStart As Long
Open "MyTextFile" For Binary As #3
ReverseData = Space$(LOF(3))
Get #3, , ReverseData
AllText = ReverseData
' Decryption
J = 0
For I = Len(ReverseData) To 1 Step -1
    J = J + 1
    Mid$(AllText, J, 1) = Mid$(ReverseData, I, 1)
    ZZ = Asc(Mid$(AllText, J, 1))
    Select Case ZZ
    Case 32 To 126
        Mid$(AllText, J, 1) = Chr$(ZZ + 95)
    Case 127 To 221
        Mid$(AllText, J, 1) = Chr$(ZZ - 95)
    Case Else
    End Select
Next
Start = InStr(AllText, "~")
TestPreamble = Left$(AllText, Start - 1)
Start = InStr(Start, AllText, "^")
EndStart = InStr(Start, AllText, "~") ' Second Test Locater
TestFile1 = Mid$(AllText, Start + 1, EndStart& - Start&)
Start& = InStr(EndStart, AllText, "^")
TestFile2 = Mid$(AllText, Start + 1)

---

MyTextFile is located on the App directory. I am wondering if the Chinese machine is somehow looking at the wrong subdirectory. If so, then the file would be opened somehere else anyway and have zero bytes to work with. That sets up a situation where Start = 0 and TestPreamble is subsequently invalid and produce the error 5.

Could that be it? If so, why is it looking at a directory other than the default App directory?

You could use my Insert Procedure Names Add-In to trace and/or show the last procedure that executes.

You can try explicitly defining the location of the file

Code:

---

Open app.path & "\MyTextFile" For Binary As #3

---

and using freefile to derive the filehandle

Quote:

---

Originally Posted by MartinLiss

You could use my Insert Procedure Names Add-In to trace and/or show the last procedure that executes.

---

Well, that means working with the Chinese machine, right? Unfortunately, the App is so big (40 Mb) that e-mailing it is almost impossible.

Should I be using App.Path to specify the exact directory of this file so that the machine has to look at that directory and cannot look elsewhere to find the text file that I am opening in binary?

I have never had to do that before, but then times have changed and who knows what the Chinese machines are doing?

(Techno's post and mine crossed. I think that's it.)

technorobbo is spot on. I don't know how you have been so lucky up to now.

Quote:

---

Originally Posted by Code Doc

MyTextFile is located on the App directory.

---

So why aren't you specifying that in your code?

Quote:

---

I am wondering if the Chinese machine is somehow looking at the wrong subdirectory.

---

Yes, because you aren't telling it where to look.

Quote:

---

If so, why is it looking at a directory other than the default App directory?

---

The App directory is not the default, it just happens to usually be the same path as the default - which is the Current Working Directory.

By default, the Current Working Directory will be the same path as App.Path, but it can be changed before the program starts (by editing the "Start in" path of the shortcut to your program), and can also change while the program is running (various causes, including ChDir function, Common Dialog [control or API], etc).


To avoid this kind of situation, you should always specify the full path of files.

Thank you all. Code being modified. Not sure why this never cropped up until it made it to Asia. Even there, only a few users have reported it.

BTW: I do have the "Start In" path set as the App Directory in the shortcut to the program. It seems a bit strange that this situation occurred. Perhaps it was forced by a user.

Quote:

---

Originally Posted by Code Doc

BTW: I do have the "Start In" path set as the App Directory in the shortcut to the program.

---

That only means it will be the same as the app directory at the moment that the program starts - there are many things (including the two I mentioned before, and many more) which can change it while your program is running.

The only way a user could change it is by editing the "Start In" (or running the program from a command prompt or similar), so the cause is almost certainly based on your code (or a component etc that your program uses) in some way - but it doesn't really matter, as the solution for all causes is far simpler than working out what the actual cause was.

Si said, "The only way a user could change it is by editing the "Start In" (or running the program from a command prompt or similar), so the cause is almost certainly based on your code (or a component etc that your program uses) in some way - but it doesn't really matter, as the solution for all causes is far simpler than working out what the actual cause was."
------------------
Today I think I figured out what the user did. She used My Computer to either delete the resource file on the App directory, rename it, or move it. By doing any of these, I replicated her error 5 perfectly.

Si, et al., doesn't that mean that even if I specify in the code the exact App.path location of the file, the software will still crash if the file has been renamed, deleted, or moved? I see no way around this unless we make this resource file impossible to rename, delete, or move.

If that is not possible, then the only alternative is to check for the existence of all the resource files on the App directory and then ask the user to reinstall the software if any one of them is missing.

Also, can we remove the "Thread Resolved" feature to open up more discussion? At this point, I fear this one is not resolved. :ehh:

I did it for you by editing the Subject and selecting No Icon. That's probably something you could have done but no problem.

Quote:

---

Originally Posted by Code Doc

... Si, et al., doesn't that mean that even if I specify in the code the exact App.path location of the file, the software will still crash if the file has been renamed, deleted, or moved? I see no way around this unless we make this resource file impossible to rename, delete, or move.

---

Suggestion. If your app absolutely requires files to be present, then check for those files always. If they are not found, popup a message saying that "File XYZ could not be found". And close your application. If possible, your app can try to create a new file and populate it with default values?

Another thing to consider, especially on Vista/XP. If the user has no admin privileges and the app is installed in the All Users App folder(s), i.e., that's where App.Path is, then the user should not be able to update the file(s) --permission denied errors.

Last but not least, this may be an issue you will have to deal with. If the app is in a folder that contains unicode characters, accessing that path may give you Error 52. I don't know if this is also true on Chinese OEM machines. But on my U.S. machine,
1. I placed an exe in a folder that contained unicode characters
2. Hit a button that is only displaying Dir$(App.Path & "\*.*")
3. Error 52.
Here is the screenshot and you can see the App.Path for the exe does have unicode characters. Using unicode aware APIs to access files may be necessary...
Attachment 72232

Thanks, Fox (and Martin). Unfortunately, I cannot recreate the resource files with default values. These files are huge. I am already looking for one of the resource files and then shut down if that is missing. However, one other one could have caused the same error 5 if it is missing. I am starting to think that some vandalism could be going on here with multiple users of the same computer.

However, what if I installed all resource files to the AppDataPath directory, which makes them only accessible to the user who installed them? In your judgment, is that padlock safe enough? :ehh:

The error 52 is another issue. Gasp! Right now I can only swallow one bite at a time.

How about installing a second copy of the res file giving it a different name and folder. Then check to see if the primary res file is there. If not then copy the other one giving it the original name?

Quote:

---

Originally Posted by MartinLiss

How about installing a second copy of the res file giving it a different name and folder. Then check to see if the primary res file is there. If not then copy the other one giving it the original name?

---

Actually MartinLiss' idea is a very good one. If you install it into the All Users AppData folder, then those ppl without admin privileges can't delete it or modify it. If the file(s) in the personal AppData path are gone, copy them from the All Users AppData path. If they aren't in that folder either, then a person with admin privileges got rid of them.

I have now coded all suggestions from Martin, Si, Techno, and the Fox. Upon invocation, the program checks for the existence of the resource files on the App path. If it cannot find any one of them, it looks on another directory for the backups that I am now installing. If that exists, it copies the backup file to the App path and continues. If the backup does not exist either, I advise for another install and then exit. There is only so much you can do, right?

I also check for error 52 before any of these operations. If that occurs, I advise fror a non-Unicode directory reinstallation, a Windows Language setting set to English, and then exit. BTW, one of the Asian users who encountered error 52 on startup supplied a screenshot showing a desktop with Chinese characters all over the place. I imagine the directory tree is also packed with them.

Anyway, do these seem like a few steps in the right direction?

You could hide one or both of the resource files.

Well, in my opinion if you are going to market your app to other countries, it should minimally support unicode. Regarding the Error 52, that is very easy to work around with APIs: CreateFileW (to open a file), ReadFile, WriteFile, CloseHandle, GetFileAttributesW (to test if it exists) and GetFileSize are a few that will help do the job. Note that the W versions of the APIs should be tweaked to receive Long vs String parameters. And the file path/name then should be passed with StrPtr(). Supporting unicode path/file names isn't exactly easy, but it isn't difficult either.

Just my two cents.

Quote:

---

Originally Posted by MartinLiss

You could hide one or both of the resource files.

---

Marty, et al., I am ready to hide them all, even if that can be easily overridden. Suppose I did this when the program first executes for each resource file:

Code:

---

If Len(Dir$(AppPath & "MyResourceFile")) Then SetAttr AppPath & "MyResourceFile", vbHidden

---

If later I have to repair or replace the file, I can do that again after the backup restores it. Will the Uninstaller still be able to wipe the slate clean?

Also, it seems like hiding it doesn't really hide it. My Computer reveals about all of it. Who does it hide it from? Hack once said, "Nothing is hidden if show all files is checked in Windows Explorer." One has to wonder how many users know this.

I don't know how your Windows Explorer is set up but in Tools|Folder Options|View|Hidden files and folders there's a Show hidden files and folders option that you may have set. In any case if you give the backup resource file some strange and/or important-sounding name then that should be protection enough but if you also hide it then I would think that that would be more than enough.

Vb6 out of the box will read and display files even with Unicode Chinese filenames on a U.S. system. The trick is that you need to set your default non-Unicode locale to Chinese via Control Panel/Regional settings and reboot. You get Chinese in Form TitleBar, IDE window and the Debug window.

AFAIK using non-Unicode Chinese locale translates Unicode to MBCS Chinese so that it can work with non-Unicode applications such as Vb6.

In this demo App.Path is Unicode Chinese and is handled OK by Vb6 by loading a ANSI text file with a Unicode App.Path.

http://www.vilapontanegra.com/images/Vb6Chinese.png

Is it possible you are hard some coding some paths such as "Program Files".
On Portuguese (BR) it is "Arquivos de Programas".
You can use API or Environ$ do get the correct path no matter what language your OS is.

Print Environ$("ProgramFiles")
C:\Program Files

Quote:

---

Originally Posted by MartinLiss

I don't know how your Windows Explorer is set up but in Tools|Folder Options|View|Hidden files and folders there's a Show hidden files and folders option that you may have set. In any case if you give the backup resource file some strange and/or important-sounding name then that should be protection enough but if you also hide it then I would think that that would be more than enough.

---

I am configured to show hidden files, and I agree that it is buried rather deep.

One thing I did discover is that Dir$() requires the vbHidden parameter (value = 2) to show if a hidden file exists. However, if the vbHidden parameter is included when looking for a normal file, the correct string is nevertheless returned if the file is present. That's rather programmer friendly. :ehh: