Announcement

Collapse
No announcement yet.

Error 55 triggering unexpectedly

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error 55 triggering unexpectedly

    Client informs me that my app which has run fine for hundreds of others for many years is generating an error for him. I'm running out of ideas on how to resolve the issue.

    My app is structured like so:

    Code:
    PBMAIN()
       Open "myapp.sys"
       call RegistrationProc
       <do stuff>
       Close "myapp.sys"
    END PBMAIN
    
    RegistrationProc()
       <do stuff>
       <user clicks "I agree">
            Close "myapp.sys"
            <call Fn that opens/writes/closes a file, pass "myapp.sys" and data buffer>
            Open "myapp.sys"
    END RegistrationProc
    When client clicks "I agree", the app is displaying an error message for Error 55 - File is already open. I've already confirmed that the app was installed on his personal PC, he's the only one running the app and he has only opened one instance of the app.

    Could this be caused by Windows disk write caching?
    Bernard Ertl
    InterPlan Systems

  • #2
    Is this Windows 7 ? I have had this problem on some Windows 7 machines telling me the file is opened when it is definately not. I decided to upgrade everybody to Windows 8 then 10. This solved my problems.

    Comment


    • #3
      I have asked the client for Windows version and am waiting for his answer.
      Bernard Ertl
      InterPlan Systems

      Comment


      • #4
        Client is using Windows 10 Pro 64bit.
        Bernard Ertl
        InterPlan Systems

        Comment


        • #5
          Bern, this is what I see:
          Code:
          PBMAIN()
            Open "myapp.sys"    'step 1
             call RegistrationProc
             <do stuff>
            Close "myapp.sys"   'step 4
          END PBMAIN
          
          RegistrationProc()
             <do stuff>
             <user clicks "I agree">
            Close "myapp.sys"   'step 2
                  <call Fn that opens/writes/closes a file, pass "myapp.sys" and data buffer>
            Open "myapp.sys"    'step 3
          END RegistrationProc
          Likely this is the problem:
          <call Fn that opens/writes/closes a file, pass "myapp.sys" and data buffer>

          if you are not using FREEFILE to generate the file handle.
          From the docs
          Similarly, attempting to OPEN a file using a file number that is
          already in use will result in a run-time Error 55 ("File is already open ").
          For this reason, programs that use hard-coded file numbers should take
          special care to close files before the file number is used again.
          In addition, code that may be used by more than one thread should use
          FREEFILE and avoid hard-coded file numbers.

          Question...
          Are you using a MUTEX to prevent app reentry?

          Would this not be more appropriate?
          Code:
          PBMAIN()
             LOCAL AppSys as LONG
          
             AppSys = FREEFILE
             OPEN "myapp.sys" FOR OUTPUT SHARED AS #AppSys
             call RegistrationProc
             <do stuff>
             Close #AppSys
          END PBMAIN
          
          FUNCTION RegistrationProc() AS LONG
             <do stuff>
             <user clicks "I agree">
                  <call Fn that writes a file, pass AppSys and data buffer>
          END FUNCTION

          Comment


          • #6
            Hi Jim,

            You are correct that the error is occurring during the OPEN statement within the <Fn> (TRY/CATCH is calling my error handler). I *am* using FREEFILE to ensure a unique file handle for the open.

            I'll reiterate that my code works just fine on my computer and for hundreds of others. This client is the first report I've ever seen of this issue. This app has been in use for many years.
            Bernard Ertl
            InterPlan Systems

            Comment


            • #7
              Howdy, Bern!

              If your customer reboots does the error occur the first time he opens it?

              Did your confirmation include looking at Task Manager to confirm that only one instance was running, including looking in the background processes?

              If the customer was to try and open it a 2nd time, do you detect and prevent that?

              I didn't know you could say "Open "myapp.sys"", with no other parameters. In my copy of Help, the fileNum& is not shown as optional - or was that just a shortcut description of what you're doing.

              Try a simple, separate app that opens and closes the file to see if it gets the same error:

              Code:
              Function PBMain()
              'open, then close file
              End Function
              Finally, can you pull out just the minimum code that you know to fail on his PC, and show that to us? The exact code?

              Comment


              • #8
                Error 55 means Powerbasic handle already open and has nothing to do with a separate OPEN in the same or another process.

                It should not make any difference as long as you are using FREEFILE() but I do not understand why you are not opening and closing the "myapp.sys" fie in the same procedure in which you use them. Not that it should not work but I never really liked opening and closing files except in the procedure which uses (reads/writes) that file. Makes troubleshooting a whole lot easier.

                But whenever I do open a file in another procedure, I PASS the handle as a parameter to the using procedure. (Which you'd have to do using FREEFILE() anyway unless you use a GLOBAL variable).

                MCM



                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  The client says he has rebooted and the error occurs every time. The application maintains a file lock on myapp.sys (keeping it open) to prevent multiple instances from running. My "code" was a shortcut description to describe the file open/closing sequence. I did not post the full code. Full code has worked fine on hundreds of computers for several years. I'm not in a position to impose on the client for testing/troubleshooting as he is really more of a potential client that is trying to evaluate our software. If anyone here has Win 10 Pro 64 bit and would like to try testing the app for me that would be great. I can PM a link to download the install package. It's a matter of install, run and click to see the issue (if it happens - I have not been able to reproduce the error).

                  Code for <Fn> is very simple (and ** does ** use FREEFILE):
                  Code:
                  MACRO mBufferToFile (sFile,Buffer,ParentProcType)
                  
                     NoError = %False
                     Dev = FREEFILE
                     DO
                        TRY
                           OPEN sFile FOR BINARY AS #Dev
                           PUT #Dev, Buffer
                           SETEOF #Dev
                           CLOSE #Dev
                           NoError = %True
                        CATCH
                           IF ErrorHandler&( ERR, sFile) <> %IDRETRY THEN
                              CLOSE #Dev
                              EXIT ParentProcType
                           END IF
                        END TRY
                     LOOP UNTIL NoError = %True
                  END MACRO
                  Bernard Ertl
                  InterPlan Systems

                  Comment


                  • #10
                    Howdy, Bern!

                    I'm not in a position to impose on the client for testing/troubleshooting as he is really more of a potential client
                    Yes, it is an awkward position to be in. Even so, asking the customer to run a test that might help understand the issue seems not to be much of a burden. Perhaps even a discount to that customer for any future purchase might grease the wheel?

                    I've made such a request to several of my customers and have always gotten very polite cooperation.


                    Comment


                    • #11
                      Also, Bern!

                      I noticed something funny the other day - I tried to make a file myfile.lnk. It seemed to work but it didn't look right in Explorer. Not wanted to spend time on it, I just renamed the extension and went about my business.

                      Is the ".sys" extension somehow reserved for special use by Win10, at least on your customer's PC? Anything remotely possible where that extension - on this particular user's PC - is protected? I kind of doubt it, but my experience with .lnk suggests that other extensions might have problems?

                      Easy to test - on that customer's PC change the file name. But, your inability to have access to the user's PC is an inhibitor.

                      Comment


                      • #12
                        I also recommend changing the file name and extension. On that particular system the file properties may have changed to be protected. As in needing elevated permissions. What could have led to that? Perhaps a corrupted User account.

                        Comment


                        • #13
                          Originally posted by Bern Ertl View Post
                          The client says he has rebooted and the error occurs every time. The application maintains a file lock on myapp.sys (keeping it open) to prevent multiple instances from running.
                          Ask me again why I use a Mutex to ensure only one instance is running



                          Comment


                          • #14
                            I'd also be looking at the problem machine's AV. It possibly doesn't like any application messing with a "system file" i.e. one with a .sys extension.
                            (Using .sys for the extension is probably not a good idea, given its historical use for windows System Files which are by default "Hidden/Readonly/Systerm")

                            Comment


                            • #15
                              What Stuart said!

                              I'd be surprised if the the issue at hand isn't caused by some kind of malware prevention/detection going on, trying to prevent a process from not only open, but even maipulating a *.sys file. That's the typical extension of a device driver, which runs in ring 0 and therefore has full system access aka "that malware can manipulate everything".

                              I expect this to be a one time process. Like with aninstallation, ask that customer to run your application "As Administrator" and see if that makes a difference.

                              As an alternative, write the new content to a temporary file, use the Win32 API MoveFileExA to replace the original file upon reboot.

                              Comment


                              • #16
                                Originally posted by Bern Ertl View Post
                                The client says he has rebooted and the error occurs every time. The application maintains a file lock on myapp.sys (keeping it open) to prevent multiple instances from running. My "code" was a shortcut description to describe the file open/closing sequence. I did not post the full code. Full code has worked fine on hundreds of computers for several years. I'm not in a position to impose on the client for testing/troubleshooting as he is really more of a potential client that is trying to evaluate our software. If anyone here has Win 10 Pro 64 bit and would like to try testing the app for me that would be great. I can PM a link to download the install package. It's a matter of install, run and click to see the issue (if it happens - I have not been able to reproduce the error).

                                Code for <Fn> is very simple (and ** does ** use FREEFILE):
                                Code:
                                MACRO mBufferToFile (sFile,Buffer,ParentProcType)
                                
                                NoError = %False
                                Dev = FREEFILE
                                DO
                                TRY
                                OPEN sFile FOR BINARY AS #Dev
                                PUT #Dev, Buffer
                                SETEOF #Dev
                                CLOSE #Dev
                                NoError = %True
                                CATCH
                                IF ErrorHandler&( ERR, sFile) <> %IDRETRY THEN
                                CLOSE #Dev
                                EXIT ParentProcType
                                END IF
                                END TRY
                                LOOP UNTIL NoError = %True
                                END MACRO
                                Have you tried putting a CLOSE before the open, just after dev=FREEFILE?
                                It should never be necessary, but ... ???
                                The world is strange and wonderful.*
                                I reserve the right to be horrifically wrong.
                                Please maintain a safe following distance.
                                *wonderful sold separately.

                                Comment


                                • #17
                                  Shouldn't that be #DEV = FREEFILE not DEV = FREEFILE

                                  Comment


                                  • #18
                                    No, "#" not used with FREEFILE. With some other commands it is mandatory, optional with others.

                                    Cheers,
                                    Dale

                                    Comment


                                    • #19
                                      Client installed my app on another computer and it's working as intended on the new install/computer. Short term problem solved.

                                      FTR, on client's Win 10 Pro 64 bit machine, my app did open and read the myapp.sys file initially. It's the close and re-open that isn't working as expected. I'd love to troubleshoot the issue, but I'm not able to reproduce the issue on any computers at my disposal, so it's definitely related to something unique in this client's computer set up. My suspicions before posting here were either something related to Windows file write caching (or another setting) causing an asynchronous timing error (is it possible?) or possibly AV wonkyness. I did suggest to client to try running the app with administrator rights, but client either isn't savvy enough to figure out how to do this or can't get permission from the company's IT dept to do it.

                                      I was hoping someone here might have experienced something similar or be able to assist with testing and reproducing the error.
                                      Bernard Ertl
                                      InterPlan Systems

                                      Comment


                                      • #20
                                        Originally posted by Stuart McLachlan View Post
                                        Ask me again why I use a Mutex to ensure only one instance is running
                                        File lock prevents app from being run on different workstations in case the app is installed on a network drive. I don't think a Mutex will do the same.

                                        Bernard Ertl
                                        InterPlan Systems

                                        Comment

                                        Working...
                                        X