Announcement

Collapse
No announcement yet.

Error 55 triggering unexpectedly

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

  • #21
    This works on my system WIN 10 Home 2004, PBWIN10.4, J.Roca includes, Windows Defender, Windows Malware detector, Administrator Account.
    No errors

    Click image for larger version  Name:	New Bitmap Image.jpg Views:	0 Size:	6.4 KB ID:	795595

    Code:
    #COMPILE EXE
    #DIM ALL
    
    FUNCTION PBMAIN () AS LONG
        LOCAL AppSys AS LONG
        LOCAL nFile  AS LONG
        LOCAL Varx   AS STRINGZ * 500
    
        Varx = "hello there User"
    
    
        '<DO stuff>
        '<USER clicks "I agree">
    
        nFile = OpenAFile(EXE.PATH$ + "myapp.sys", "BINARY", 0)
        IF nFile = 0 THEN
            EXIT FUNCTION
        ELSE
            PUT #nFile, 1, Varx
            SETEOF #nFile
        END IF
    
        '<do stuff>
        ? "Program end"
        CLOSE #nFile
    END FUNCTION
    
    '_________________________________________________________________
    '
    '  FUNCTION OpenAFile
    '_________________________________________________________________
    
    FUNCTION OpenAFile(PathTo AS ASCIIZ, IOtype AS STRING, FileLength AS LONG) AS LONG
        'FileLength is only needed for Binary and Append
        LOCAL FailingFile AS STRING
        LOCAL nFile       AS LONG
    
        nFile = FREEFILE
        'Errs = ERR  'KEEPS A RUNNING TRACK OF ERRORS
        ERRCLEAR
    
        FUNCTION = 0 ' means error opening file
    
        FailingFile = TRIM$(FileNam(PathTo))
    
        SELECT CASE IOtype
            CASE "INPUT"
                OPEN PathTo FOR INPUT ACCESS READ LOCK SHARED AS nFile
                IF ERR THEN
                    ERRCLEAR
                    CLOSE #nFile
                    'CALL FLASH_NOTE_FOR_SECONDS("Unable to open file " + FailingFile + " for input.", 2)
                    ? "Unable to open file " + FailingFile + " for input."
                    EXIT FUNCTION
                END IF
    
            CASE "OUTPUT"
                OPEN PathTo FOR OUTPUT ACCESS WRITE LOCK SHARED AS nFile
                IF ERR THEN
                    ERRCLEAR
                    CLOSE #nFile
                    'CALL FLASH_NOTE_FOR_SECONDS("Unable to open file " + FailingFile + " for output.", 2)
                    ? "Unable to open file " + FailingFile + " for output."
                    EXIT FUNCTION
                END IF
    
            CASE "BINARY"
                OPEN PathTo FOR BINARY AS nFile LEN = FileLength
                IF ERR THEN
                    ERRCLEAR
                    CLOSE #nFile
                    'CALL FLASH_NOTE_FOR_SECONDS("Unable to open file " + FailingFile + " for binary.", 2)
                    ? "Unable to open file " + FailingFile + " for binary."
                    EXIT FUNCTION
                END IF
    
            CASE "APPEND"
                OPEN PathTo FOR APPEND ACCESS READ WRITE LOCK SHARED AS nFile LEN = FileLength
                IF ERR THEN
                    ERRCLEAR
                    CLOSE #nFile
                    'CALL FLASH_NOTE_FOR_SECONDS("Unable to open file " + FailingFile + " for append.", 2)
                    ? "Unable to open file " + FailingFile + " for append."
                    EXIT FUNCTION
                END IF
    
        END SELECT
    
        FUNCTION = nFile
    END FUNCTION
    
    
    '_________________________________________________________________
    '
    ' FileNam Get file name part of given path & name
    '_________________________________________________________________
    
    FUNCTION FileNam (BYVAL Src AS STRING) AS STRING
        LOCAL x AS LONG
    
        x = INSTR(-1, Src, ANY ":/\")
        IF x THEN
            FUNCTION = MID$(Src, x + 1)
        ELSE
            FUNCTION = Src
        END IF
    
    END FUNCTION

    Comment


    • #22
      Which AV is used? Exclude folder. Submit to AV company.
      How long is an idea? Write it down.

      Comment


      • #23
        Note:
        Windows Defender exclusions do not work on Windows Malware Detector.

        Comment


        • #24
          Bern,
          I'm thinking that 1 of your clients has installed Windows 10 2004. More secure than the previous versions. To get a better handle on the errors you should probably upgrade.

          I reinstalled your app but did not launch it. Then I ran my app with these changes.

          Code:
              LOCAL AppLocation AS ASCIIZ * %MAX_PATH
          
              AppLocation = "C:\Program Files (x86)\eTaskMaker Wizard Demo\"
              Varx = "hello there User"
          
          
              '<DO stuff>
              '<USER clicks "I agree">
          
              nFile = OpenAFile(AppLocation + "eTM.sys", "BINARY", 0)
              'nFile = OpenAFile(EXE.PATH$ + "myapp.sys", "BINARY", 0)
          My app produced no errors.

          Then I opened your app and got the Permission Denied error.

          Then I ran my app and it produced an error that it was unable to open eTM.sys.

          Then I closed your app and tried running my app. Again no error.

          It seems apparent that your app is trying to open eTM.sys twice.

          Personally, I would scrap the TRY/CATCH method and the MACRO.

          Comment


          • #25
            Oh, I see terrible secruity practice:

            Code:
            AppLocation = "C:\Program Files (x86)\eTaskMaker Wizard Demo\"
            Never ever install a writeable file in %ProgramFiles(x86)% or %ProgramFiles%. A normal user account hasn't got write permissions in these folders (and subfolders). Reading is fine, though.

            For persiting information that's what %AppData%/%LocalAppData% (current user) or %ProgramData% (all users) is for.

            Really folks, do yourself a favor, spare yourself (and your customers) some headaches and make it a good habit to follow these security practices. They're not new - in fact, they're around since NT4. Only that MS started to enforcing those more and more ever since Vista was released. And "but ... but ... it worked in the past" won't lead to any useful results. Implementing a workaround now only means you bought yourself a bit of time until it finally breaks. This time is better spend with implementing a future-proved way of doing it.

            Comment


            • #26
              Originally posted by Knuth Konrad View Post
              Never ever install a writeable file in %ProgramFiles(x86)% or %ProgramFiles%. A normal user account hasn't got write permissions in these folders (and subfolders). Reading is fine, though.

              For persiting information that's what %AppData%/%LocalAppData% (current user) or %ProgramData% (all users) is for.
              This!

              If you really need to keep it all in one directory branch, don't use the "Program Files" tree; use a directory off the root.

              Comment


              • #27
                If a test program was posted with actual file paths and where program is found we could find the problem.

                Added/changed a couple things to get to compile.
                Sleep between retries may not be needed, but is normally done.
                Exit ParentProcType didn't compile.
                PUT #Dev,Buffer didn't compile.
                Can't see if "myapp.sys" is left open in registration proc without some code.
                Dont' know if there is a version control and manifest to make virus checkers happy.
                Code:
                #DIM ALL
                #INCLUDE "win32api.inc"
                
                FUNCTION ErrorHandler(MyErr AS LONG, sFile AS STRING) AS LONG
                 ? USING$("MyErr # File = &",MyErr,sFile)
                END FUNCTION
                
                MACRO mBufferToFile (sFile,Buffer,ParentProcType)
                   LOCAL NoError AS LONG 'added this
                   LOCAL dev     AS LONG 'added this
                
                   NoError = %False
                   Dev = FREEFILE
                   DO
                      TRY
                         OPEN sFile FOR BINARY AS #Dev
                         'PUT #Dev, Buffer              'does not compile
                         PUT  #Dev,1,Buffer             'added this
                         SETEOF #Dev
                         CLOSE #Dev
                         NoError = %True
                      CATCH
                         IF ErrorHandler&( ERR, sFile) <> %IDRETRY THEN
                            CLOSE #Dev
                            EXIT 'ParentProcType       'how does this work
                         END IF
                      END TRY
                   LOOP UNTIL NoError = %True
                END MACRO
                
                FUNCTION RegistrationProc() AS LONG
                '   <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 FUNCTION
                
                FUNCTION PBMAIN () AS LONG
                 LOCAL sFile,sBuffer AS STRING
                 LOCAL result,ParentProcType AS LONG
                 sFile = "myapp.sys"  'what should this be?
                 sBuffer = "The time is "+TIME$
                 mBufferToFile(sFile,sBuffer,ParentProcType)
                 ? "Done"
                END FUNCTION
                How long is an idea? Write it down.

                Comment


                • #28
                  Examples of INI file (or other program data files) location using system constants; multiple authors, multiple functions

                  https://forum.powerbasic.com/forum/u...-that-ini-file
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #29
                    Originally posted by Stuart McLachlan View Post

                    This!

                    If you really need to keep it all in one directory branch, don't use the "Program Files" tree; use a directory off the root.
                    There has been an interesting development over the past years, where even Microsoft participates: for the purpose mentioned by Stuart of keeping all program related data (binaries, configs, data etc.) within ONE folder where the user has write permissions, more and more programs are installed in %AppData%\Local or %AppData%\Roaming. Check yours. It's a wild mix of configuration/program data, as initially envisioned and binaries these days.

                    Which kinda defeats the initial purpose of %ProgramFiles% / %ProgramFiles(x86)%: a secure(d) location to store executables that can be altered without raised privileges aka "malware can't mess with it".

                    Comment


                    • #30
                      Originally posted by Knuth Konrad View Post

                      There has been an interesting development over the past years, where even Microsoft participates: for the purpose mentioned by Stuart of keeping all program related data (binaries, configs, data etc.) within ONE folder where the user has write permissions, more and more programs are installed in %AppData%\Local or %AppData%\Roaming. Check yours. It's a wild mix of configuration/program data, as initially envisioned and binaries these days.
                      .
                      Maybe OK if there's only one user on the machine that needs to use the application since %Appdata% is specific to the logged in user..

                      And it's a PITA for backup or relocation because %AppData% and its sub-directories are hidden by default and your average user wouldn't have a clue how to find their files.

                      Comment


                      • #31
                        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.
                        Ideas:

                        1. Did virus checker block or place in quarantine (can virus checker be turned off while testing)
                        2. Did path change
                        3. Did file or folder attribute change to read-only or some unwanted state
                        4. Did share change
                        5. Did logon/user name change
                        6. Is path a secret?
                        7. Can file be renamed and deleted/recreated (corrupt registry)
                        8. Has CHKDSK /F ever been run corrupt file table (first backup)
                        9. Did machine name change

                        Impossible things:
                        10. Did program change, not closing a file or using wrong or duplicate name or handle
                        11. Is an error check after every i/o statement
                        12. Conflict by another program running such as task scheduler
                        13. ATTRIB filename run
                        14. Did user change network configuration
                        15. User installed a previous version
                        16. Incorrect system date causing untrapped registration error
                        17. Corrupted memory or machine never rebooted
                        18. Conflict with online backup system
                        19. Other instance of program started but not ending program or closing file


                        See posts #19 and #20. May not be able to duplicate. .SYS file is used as a lock file that could be used on a network.
                        Last edited by Mike Doty; 24 Jun 2020, 08:57 AM.
                        How long is an idea? Write it down.

                        Comment


                        • #32
                          20. Client double clicked on Task Bar icon.

                          22. Client double clicked on Desktop icon when single click was the default.
                          23. Bad app design in that it tries to open the sys file twice in effect blocking its own access to the file.
                          24. Not enough intelligence built in to the app to troubleshoot problem areas.
                          25. Not enough wait states to deal with OS latency. (Could change the app routine priority to something other than normal)
                          26. "Reset my PC" is your friend. ***** Tell your Customer to use it... *****

                          Comment


                          • #33
                            Client installed my app on another computer and it's working as intended on the new install/computer. Short term problem solved.
                            21. Installer error causing a corrupt shortcut or registry entry. Manually recreate shortcut with another name.
                            27. Retry attempts if there is a network issue. Looks like no retries.

                            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.
                            Curious if potential client got to run on the problem machine? I have had shortcuts go bad.
                            Last edited by Mike Doty; 24 Jun 2020, 11:14 AM.
                            How long is an idea? Write it down.

                            Comment


                            • #34
                              Originally posted by Stuart McLachlan View Post

                              Maybe OK if there's only one user on the machine that needs to use the application since %Appdata% is specific to the logged in user..
                              That's why I mentioned %ProgramData% in [url=https://forum.powerbasic.com/forum/user-to-user-discussions/powerbasic-for-windows/795522-error-55-triggering-unexpectedly?p=795633#post795633[/url] in my post above. It's the equivalent of "All Users" these days.

                              And it's a PITA for backup or relocation because %AppData% and its sub-directories are hidden by default and your average user wouldn't have a clue how to find their files.
                              Depends on the how the backup is done. If done manually by the users: yes. But then again he did chose to backup himself, he hopefully is familair enough with Windows to know what he's doing. If he uses a some kind of software (more likely, I think), a couple of which I looked at in the past will offer to backup the user's profil, which includes %AppData%.
                              Last edited by Knuth Konrad; 25 Jun 2020, 03:17 AM. Reason: Quote fixed.

                              Comment


                              • #35
                                I just thought of another potential source. (Must be really rusty that it took this long).

                                Memory corruption totally unrelated to the file access and conceivably caused by a programming problem (e.g. failure to test for error) hundreds or even thousands of lines of source code removed from where you are looking can cause "errors which should never happen" - which certainly sounds like this.

                                AND. that the software does not get this error on another system also suggests one of those problems which is forgiven on one system but throws an error on another.

                                Your best bet to find these is...

                                First, look for undetected PB errors by compiling with #DEBUG DISPLAY

                                If that fails to provide any useful info, look for any user (programmer) calls to external functions ("win api") where the return value is not properly tested.

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

                                Comment

                                Working...
                                X