CIG_Support

@jguinch, thanks for writing up this UDF. I'm trying to use the _PrintMgr_EnumPrinters and _PrintMgr_SetDefaultPrinter. No question on how to use these two. Just that when I do the syntax checker, it complains about these functions, which I can safely ignore because I don't use them (yet) but others might: "C:\Program Files (x86)\AutoIt3\Include\PrintMgr.au3"(173,26) : warning: $ret possibly not declared/created yet $ret = $oNewPort.Put_ ~~~~~~~~~~~~~~~~~~~~~~~~~^ "C:\Program Files (x86)\AutoIt3\Include\PrintMgr.au3"(252,87) : warning: $tPortName possibly not declared/created yet $tPortName = DllStructCreate("wchar Data[512]", DllStructGetData($t_PORT_INFO_2, 1)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ "C:\Program Files (x86)\AutoIt3\Include\PrintMgr.au3"(253,90) : warning: $tMonitorName possibly not declared/created yet $tMonitorName = DllStructCreate("wchar Data[256]", DllStructGetData($t_PORT_INFO_2, 2)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ "C:\Program Files (x86)\AutoIt3\Include\PrintMgr.au3"(254,87) : warning: $tPortDesc possibly not declared/created yet $tPortDesc = DllStructCreate("wchar Data[256]", DllStructGetData($t_PORT_INFO_2, 3)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ "C:\Program Files (x86)\AutoIt3\Include\PrintMgr.au3"(834,58) : warning: $iRet possibly not declared/created yet $iRet = $oPrinter.RenamePrinter($sPrinterNewName) I tried to look up for a newer one that may have fixed the above warnings but there's nothing newer. Regards, John Babbitt

You coded: $PCName = @ComputerName $File1 = "C:\folder1\folder2\" & @computername & ".xx1" You will want to rather use: $File1 = "C:\folder1\folder2\" & $PCName & ".xx1" Otherwise, what's the purpose of $PCName if it's not to save calling @computername multiple times? Regards, John Babbitt Systems Administrator Cutler Investment Group, LLC

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!

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.

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

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

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.

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.