DriveGetType Crashes

[CIG_Support]

I have a code that calls DriveGetType.  For standard user accounts, it works fine.  For admin accounts, it crashes on this particular statement.  I already check for errors returned from this statement but that doesn't help if that statement crashes.  So, I enabled error-trapping ObjEvent before DriveGetType and got the following error:  Number 1, Description = "The directory property cannot be found in the cache."  Should not DriveGetType do its own error trapping?  What's the point of it returning an error if it doesn't do that?

This isn't exactly about the error itself but more of the DriveGetType not doing its own error-trapping.  I know that the error is related to UAC, network UNC, Trusted Sites, etc.  I've confirmed I got all those right, including signing the executable, but still get this error.  I'm still troubleshooting this odd error and would appreciate any input from those who understands this type of error.  Probably will have to replace DriveGetType with something else.

[Jos]

I curious how the error trapping would work with DriveGetType as that only works on Com events.
Maybe start with showing the script you are testing with and what you mean with crash?

Jos 

[CIG_Support]

Snippet of code:

$oTrapError = ObjEvent ("AutoIt.Error", "TrapError")
$sGotData = DriveGetType ($sDrive)
If @error Then ReportError ($cTraceL, "DriveGetType failed. Error code: " & @error & ", Description: " & $sTrapErrorDesc)
SetError (0)
$oTrapError.stop
$oTrapError=0

All the variables are defined, e.g., $sDrive passed as a parameter to this function, $oTrapError and $sTrapErrorDesc are global variables.  TrapError is another function that is called whenever an error occurs.  All it does is copy the object's error number and description into @error and $sTrapErrorDesc respectively.

When you run this under an admin account with UAC enabled and pass along "N:", for example, the statement DriveGetType crashes right there.  Without the error-trapping function, I would only see line number for where the error happened, no explanation.

[Jos]

That snippet doesn't really run.
Maybe you can post something that will run so I can have a play?

Jos

 

[CIG_Support]

I was showing where exactly it crashed,  My code is 528 lines long. :-)   Let me whip up something really small that you can execute.

 

[AshlandSG]

.

Edited October 5, 2017 by AshlandSG
Wrong account used

[Melba23]

CIG_Support & AshlandSG,

Same IP for both accounts and pretty obviously the same person posting. As multiple accounts are strictly forbidden in the Forum rules, would you care to explain just what is going on?

M23

 

[CIG_Support]

I changed firms.  Out of habit, I entered my former firm's credential.  My correct one is CIG_Support.  Another tech took over AshlandSG.

[CIG_Support]

After snipping the code down to 28 lines, I could not make DriveGetType generate an error.  The description that I got appears to be related to Active Directory even though DriveGetType activate that error.  I do use Active Directory commands elsewhere and I'm left wondering if one of the "opened" objects is somehow causing issues with DriveGetType even though I don't think they're related.

The program ran fine since January 2014.  It's only after the last Patch Tuesday Windows update that this start happening.  And, only happens within GPO Logon Script, and specifically only for admin accounts.  Works just fine running in both elevated and standard command prompt for admins, just not during logons.

It's going to take me too long to drill down the exact cause.  Since I now have my own error-trapping and standard users are not affected by this, I'm not going to worry about it any longer.

[CIG_Support]

I was still getting errors on DriveGetType since then but have been ignoring it due to time constraint.  However, I've now figured out a permanent solution and hope this helps others facing the same error.  Keep in mind this only affects users running admin elevated mode, which is exactly what happens with the GPO logon scripts.  Standard users appear to be unaffected.

First, check if the path exists with the FileExists command.  If it doesn't exist then don't do the DriveGetType.  That's it.  Such a simple workaround.  Have fun!