Announcement

Collapse
No announcement yet.

Error 76 finding drive/folder under Win10 (that used to work under Win7)

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

  • Error 76 finding drive/folder under Win10 (that used to work under Win7)

    Many years ago, I wrote several utility programs for a customer running WinXP.
    Customer later moved them to Window Server 2008 R2 with Terminal Services running Win7 Pro sessions.
    Last month that server crashed. (The network guy thinks that is was a MS Windows Update that screwed up the NAS server... I couldn't tell you...)
    Anyway, customer now has a new server running Windows Server 2016 Standard with Terminal Services running Win10 sessions.

    You guessed it - some of my old code isn't running. (I thought me and my programs would be long retired by now... this hanging around scenario is getting complicated!)

    Something totally simple that used to work flawlessly, now returns Error 76: Path Not Found.

    Code:
    If IsFolder("P:\") Then
    Tried a more specific test:
    Code:
    If IsFile("P:\DriveID_P.txt") Then
    Same error.

    More config details:
    The customer uses laptops and thin clients via RDP into the server.
    The utility program runs from the server on a mapped network drive S, and the directory being accessed is mapped as drive P.
    The maps were created via "Map a Network Drive" (same as on the old server).

    NOTE that I can open a CMD window, change drive to S:, do: DIR P:\ and see the expected contents.

    Question: what would prevent my program from being able to detect the P: drive that I can see without error from the CMD window?

    I'm guessing that it has to do with permissions and/or manifests.

    I admit that I am ignorant about manifests. When my programs originally brought up a UAC window under Win7, I was ready to get in and do whatever it would take to not have that happen, but the customer had no problem with the pop-up UAC, so the code remained unchanged, and I never learned.
    So THAT's one thing I now need urgently: where do I go for an UNDERSTANDABLE tutorial on manifests?

    But I still wonder if it's permissions... how would I be able to determine that?

    I appreciate any constructive ideas on how to pin down the cause of this error!

    Thanks,
    -John

    [ADDED] Programs are compiled under PBWin10.04 with JR includes. And I'm not doing Anything special or complex, mostly file copying. Simple enough to have run under DOS...

  • #2
    Guess checking the read-write properties is an option. Can you run the program in supervisor mode?

    Comment


    • #3
      Just remembered I had a similar problem myself. Try adding extra quotes to the filename (at the beginning and end) so test for ""P:\DriveID_P.txt"" instead of "P:\DriveID_P.txt". Or first change your path to the drive and then test for the filename without the drive-parameter.

      Comment


      • #4
        Unlikely permission is allowed to root folder P:\
        Code:
        FUNCTION PBMAIN AS LONG
          'This might show you what is expected by callers if you can get here
          ? EXE.FULL$  'or put in log file
        END FUNCTION
        How long is an idea? Write it down.

        Comment


        • #5
          I got the feeling that Mike is right.
          For the fun of it you may try WNetGetUniversalName...

          Code:
          #COMPILE EXE '#Win 9.07#
          #DIM ALL
          #INCLUDE "Win32Api.inc"
          '______________________________________________________________________________
          
          FUNCTION WinError$(BYVAL ErrorCode AS DWORD) AS STRING
           LOCAL pzError  AS ASCIIZ POINTER 'Max is 64K
           LOCAL ErrorLen AS DWORD
          
           ErrorLen = FormatMessage(%FORMAT_MESSAGE_FROM_SYSTEM OR %FORMAT_MESSAGE_ALLOCATE_BUFFER, _
                                    BYVAL %NULL, ErrorCode, %NULL, BYVAL VARPTR(pzError), %NULL, BYVAL %NULL)
           IF ErrorLen THEN
             REPLACE $CRLF WITH $SPC IN @pzError
             FUNCTION = "Error" & STR$(ErrorCode) & " (0x" & HEX$(ErrorCode) & ") : " & @pzError
             LocalFree(pzError)
           ELSE
             FUNCTION = "Unknown error" & STR$(ErrorCode) & " (0x" & HEX$(ErrorCode) & ")"
           END IF
          
          END FUNCTION
          '_____________________________________________________________________________
          
          FUNCTION PBMAIN() AS LONG
           LOCAL pzRemoteNameInfo AS REMOTE_NAME_INFO POINTER
           LOCAL zNameInfo        AS ASCIIZ * %MAX_PATH
           LOCAL zLocalPath       AS ASCIIZ * %MAX_PATH
           LOCAL BufferSize       AS DWORD
           LOCAL LastError        AS LONG
          
           'At CMD prompt type: "D:\>net use X: \\ComputerName\C$\Tmp"
           'At CMD prompt type: "D:\>net use X: /delete" when done with test
          
           zLocalPath       = "X:"
           pzRemoteNameInfo = VARPTR(zNameInfo)
           BufferSize       = %MAX_PATH
           IF WNetGetUniversalName(zLocalPath, %REMOTE_NAME_INFO_LEVEL, zNameInfo, BufferSize) = %NO_ERROR THEN
             MessageBox(%HWND_DESKTOP, "Local name = [" & zLocalPath & "]" & $CRLF & _
                        "UniversalName  = [" & @[email protected]  & "]" & $CRLF & _
                        "ConnectionName = [" & @[email protected] & "]" & $CRLF & _
                        "RemainingPath  = [" & @[email protected]  & "]", _
                        "WNetGetUniversalName - Success", %MB_OK OR %MB_TOPMOST)
           ELSE
             LastError = GetLastError
             MessageBox(%HWND_DESKTOP, zLocalPath & $CRLF & WinError$(LastError), _
                        "WNetGetUniversalName - Error", %MB_OK OR %MB_TOPMOST)
           END IF
          
          END FUNCTION
          '_____________________________________________________________________________
          '

          Comment


          • #6
            John,
            Also, here is a Windows 10 aware manifest.
            It call for Microsoft.Windows.Common-Controls version 6.0, note that 5.82 may be tried.
            You may interchange [level='requireAdministrator'] and [level='asInvoker'], this will ask for UAC prompt for [requireAdministrator].
            You may also enable the LongPathAware line for curiosity, this should not do any change unless you got very long path.
            Compiling the following Resource01.rc file to Resource01.pbr. In your exe put: #RESOURCE "Resource01.pbr"

            Code:
            #include "resource.h"
            
            // 0x101 ICON "SomeIcon.ico"
            
            #define IDR_MANIFEST 1 // 1 for a EXE, 2 for a DLL
            #define RT_MANIFEST 24
            
            IDR_MANIFEST RT_MANIFEST MOVEABLE PURE
            {
              "<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
            
                 <description>Windows Shell</description>
            
                 <!-- Compatibility section for Program Compatibility Assistant (PCA) -->
                 <compatibility xmlns='urn:schemas-microsoft-com:compatibility.v1'>
                   <application>
                     <!-- Windows Vista -->
                     <supportedOS Id='{e2011457-1546-43c5-a5fe-008deee3d3f0}'/>
                     <!-- Windows 7 -->
                     <supportedOS Id='{35138b9a-5d96-4fbd-8e2d-a2440225f93a}'/>
                     <!-- Windows 8 -->
                     <supportedOS Id='{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}'/>
                     <!-- Windows 8.1 Needed to report GetVersionEx 6.3 instead of 8.2-->
                     <supportedOS Id='{1f676c76-80e1-4239-95bb-83d0f6d0da78}'/>
                     <!-- Windows 10.0 Needed to report GetVersionEx 10.0 instead of 6.2-->
                     <supportedOS Id='{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}'/>
                   </application>
                 </compatibility>
            
                 <dependency>
                   <dependentAssembly>
                     <assemblyIdentity
                       type='win32'
                       name='Microsoft.Windows.Common-Controls'
                       // version='5.81.0.0'   //Me 2000
                       // version='5.82.0.0'   //XP, Server 2003, Vista, Server 2008, and Seven
                       version='6.0.0.0'       //XP, Windows Server 2003
                       // version='6.10.0.0'   //[BAD!] Vista, Server 2008, and Seven
                       processorArchitecture='x86'
                       publicKeyToken='6595b64144ccf1df'
                       language='*'
                     />
                   </dependentAssembly>
                 </dependency>
            
                 //DpiAware section
                 <asmv3:application xmlns:asmv3='urn:schemas-microsoft-com:asm.v3'>
                 <asmv3:windowsSettings xmlns='http:\x2F\x2Fschemas.microsoft.com/SMI/2005/WindowsSettings'> // \x2F = 47 = "/"
                   <dpiAware>false</dpiAware>
                   // <dpiAware>true</dpiAware>
                   // <Path:LongPathAware>true</Path:LongPathAware>
                 </asmv3:windowsSettings>
                 </asmv3:application>
            
                 //Run as admin section
                 <asmv3:trustInfo xmlns:asmv3='urn:schemas-microsoft-com:asm.v3'>
                   <asmv3:security>
                     <asmv3:requestedPrivileges>
                       <asmv3:requestedExecutionLevel
                         // level='asInvoker' level='highestAvailable' level='requireAdministrator'
                         level='requireAdministrator'
                         uiAccess='false' />
                     </asmv3:requestedPrivileges>
                   </asmv3:security>
                 </asmv3:trustInfo>
               </assembly>"
            }

            Comment


            • #7
              TOO WEIRD FOR WORDS...

              OK first of all, thanks for all the suggestions. I was just beginning to test them this morning, when I got a big surprise... All of a sudden, the original code IS NOW ABLE to see the P drive just fine! WTF???

              I'll come back to this in a moment, but first another note: After I had posted the first message above and before anyone had replied, I decided to test the "is the P drive visible" code, so I copied it from the existing program to a cut-down, standalone EXE:

              Code:
              'Win10test.bas  by jhm
              ' To see why MyApp.exe cannot see the P drive, and if Manifests can fix it...
              '================================================
              #Compile Exe
              #Dim All
              
              '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
              'First try this exe without any manifest, to duplicate the existing problem.
              '  Then, try each of these (from the PB forums).
              '#Resource Manifest, 1, "d:\PB\win10theme.xml"
              '#RESOURCE MANIFEST, 1, "d:\PB\manifest L3.xml"
              '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
              
              
              Function PBMain () As Long
              
                 Call QuickPcheck
              
              End Function
              
              
              Sub QuickPcheck
                 Local sRet As String
              
                 Try
                    If IsFolder("P:\") Then         ' Is the P Drive visible to us?
                       sRet = "P:\"
                    Else
                       sRet = "Cannot see folder: P:\"
                    End If
                 Catch
                    Call NotifyUserOfError(Err, "IsFolder()")
                 End Try
                 ? "sRet = " & sRet,,"IsFolder()"
              
              
                 Try
                    ChDrive "P:"
                 Catch
                    Call NotifyUserOfError(Err, "ChDir")
                 End Try
              
              
                 Try
                    If IsFile("P:\DriveID_P.txt") Then          ' Is the P Drive identifier file visible to us?
                       sRet = "P:\DriveID_P.txt"
                    Else
                       sRet = "Cannot find file: P:\DriveID_P.txt"
                    End If
                 Catch
                    Call NotifyUserOfError(Err, "IsFile()")
                 End Try
                 ? "sRet = " & sRet,,"IsFile()"
              
              End Sub
              
              
              Sub NotifyUserOfError(ByVal lErr As Long, ByVal sText As String)
                 ? "Error: " & Trim$(lErr) & $CrLf & Error$(lErr) ,,"Error: " & sText
              End Sub
              Result: this cut-down test program ran FINE, but the identical code in my real app could not see the P drive.

              But that was yesterday...

              This morning, before starting to try all the above suggestions, I ran both the original app and the cut-down test code, and now they were BOTH able to see the P drive! Wha..???

              I had talked with my server guru yesterday, and he had checked all the permissions, etc. but could not see anything askew.

              So today, after seeing both exes running properly, I talked with him again, and he told me that another (commercial) program that had not been working the day before, was working now...

              SO, something must have changed on the server, but we cannot tell what.

              It makes me uncomfortable to think that there's something else affecting mapped drive letters... If it could suddenly decide TO work, can it suddenly decide to NOT? (Well, I suppose that's a given with everything on a Windows platform nowadays...)

              In any case, I have been motivated to proceed and learn about manifests, and incorporate them into all my code, just so I'm not relying on luck and charm...

              So I will be continuing to test the above suggestions, and I thank you all for your assistance!!!

              I found some forum threads and this link, so I'm moving ahead... https://blogs.msdn.microsoft.com/pat...and-questions/

              I'll be back with questions, I'm sure.

              Thanks,
              -John

              Comment


              • #8
                @Marcel,
                I was getting the same results running as "normal user" and "as administrator".
                I'd never tried doubling the DQs, so it will be interesting to see what that does...

                @Mike,
                The "P drive" is actually just a folder on the server that's been mapped as a letter in order to simplify access for warehouse users. We use a handful of map letters to simplify access for several other programs, and they've all worked fine.

                @Pierre,
                I'm running on my laptop from home, where there is no P drive, but I have a mapped letter P for when I go in to the office and connect to the LAN. The code in message #5 reports success because the MAP exists, even though I'm not on the network and there is no P drive here at this time.

                I've got to get to a meeting, and when I get back I will try the manifest you provided in message #6.
                Do I need to use RC.exe to make a .PBR?
                I'm using PBWin 10.04; is it OK to use:
                Code:
                #RESOURCE MANIFEST, 1, "d:\PB\PierresWin10manifest.xml"
                I'll be back in a few hours...

                Thanks, all!
                -John

                Comment


                • #9
                  Many years ago, I wrote several utility programs for a customer running WinXP.
                  Customer later moved them to Window Server 2008 R2 with Terminal Services running Win7 Pro sessions.
                  Last month that server crashed. (The network guy thinks that is was a MS Windows Update that screwed up the NAS server... I couldn't tell you...)
                  Anyway, customer now has a new server running Windows Server 2016 Standard with Terminal Services running Win10 sessions.

                  You guessed it - some of my old code isn't running. (I thought me and my programs would be long retired by now... this hanging around scenario is getting complicated!)

                  Something totally simple that used to work flawlessly, now returns Error 76: Path Not Found.
                  TOO WEIRD FOR WORDS...

                  OK first of all, thanks for all the suggestions. I was just beginning to test them this morning, when I got a big surprise... All of a sudden, the original code IS NOW ABLE to see the P drive just fine! WTF???

                  I'll come back to this in a moment, but first another note: After I had posted the first message above and before anyone had replied, I decided to test the "is the P drive visible" code, so I copied it from the existing program to a cut-down, standalone EXE:

                  @Marcel,
                  I was getting the same results running as "normal user" and "as administrator".
                  I'd never tried doubling the DQs, so it will be interesting to see what that does...

                  @Mike,
                  The "P drive" is actually just a folder on the server that's been mapped as a letter in order to simplify access for warehouse users. We use a handful of map letters to simplify access for several other programs, and they've all worked fine.

                  @Pierre,
                  I'm running on my laptop from home, where there is no P drive, but I have a mapped letter P for when I go in to the office and connect to the LAN. The code in message #5 reports success because the MAP exists, even though I'm not on the network and there is no P drive here at this time.

                  I've got to get to a meeting, and when I get back I will try the manifest you provided in message #6.
                  Do I need to use RC.exe to make a .PBR?
                  I'm using PBWin 10.04; is it OK to use:
                  Code:
                  #RESOURCE MANIFEST, 1, "d:\PB\PierresWin10manifest.xml"
                  I'll be back in a few hours...

                  Thanks, all!
                  -John
                  Does it work all the time, now?
                  Drive mapping lost, but corrected itself after reboot?
                  It sounds similar to going through every printer setting with a client and still won't print (until they turn printer off then on.)
                  Server did an update, but needed to be rebooted, etc ...
                  Router needed to be rebooted. So many things.
                  Play video below, made my day
                  How long is an idea? Write it down.

                  Comment


                  • #10
                    Solves the worlds problems...

                    <b>George W. Bleck</b>
                    <img src='http://www.blecktech.com/myemail.gif'>

                    Comment


                    • #11
                      Something totally simple that used to work flawlessly, now returns Error 76: Path Not Found.
                      The PB (10x) doc does not speak to any ERR values returned by ISFOLDER(); it only speaks to returning TRUE or FALSE.

                      Needless to say, :"insufficient code shown" (nothing shown displays ERR) but maybe ERR is not the value you should be testing when using ISFOLDER.

                      You miight try something like
                      Code:
                         S = DIR$("P:\*.*")
                      That should return at least the dot and double-dot entries and if those are returned then "P:" must be a valid folder. (Or you can test the returned file attributes)

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

                      Comment


                      • #12
                        My adding double quotes solution was the result of trying out how the developpers of Microsoft thought/think. Because with windows there always is the problem that you have the long-filename and short filename (MSDOS). When trying to copy or rename a file containing spaces in the filename (allowed in the windows long filename) you get problems as well because for windows it looks like you trie to copy/rename more than one file. By adding double quotes the exact length of the filenamestring is clear. Never forget that windows would be much slower if it didn't buffer a lot of things. Although no-one likes it, because it reduces the performance of the program you write/wrote, also adding some SLEEP instructions and/or extra DOEVENT instructions can solve a lot of problems. It gives windows time to handle/finish work you may asume to already have been handled and/or finshed while it's not. And a computer is and always stays a machine, things can go wrong. A regular restart/reboot (if possibly daily and a total shutdown and restart is even better) from a server can prevent a lot of problems because it clears a lot of buffers.

                        Comment


                        • #13
                          I don't know if you ever fully solved this John. But for anyone finding this thread after 2 years, I had the identical problem and did solve it. Putting $DQ around paths and adding a manifest didn't help, but dispensing with drive letter mappings altogether and using UNC names ( \\ServerName\folder\filename) did work most of the time.

                          However, the real problem turned out to be the filename, which started with "Setup...". Renaming the executable solved all the problems and let me go back to using drive letters.

                          Your problem might have had a totally different cause John, that that is one thing to look out for, as Windows applies different UAC and security for such filenames.

                          Comment

                          Working...
                          X