Win7 issue with TimeYmdHms ?

[MW4]

I have a script that unceremoniously ends and this is always the last line in the debug trace -- see below.

Now=TimeYmdHms( )
(16800310) VALUE STRING => "2014:05:28:04:33:02"

Running fine in XP.
Now has issues in Win7

mini debug info...
==============================
Tue 5/27/2014 11:53:01 PM
WinBatch 32 2014A
WIL DLL 6.14ana
Y:\Users\WBT\Automated\Status.exe
Windows platform: NT, version: 6.1, build: 7601 (Service Pack 1)
ErrorMode: @CANCEL
Valid Code Signature: No
UAC Manifest Settings: level="asInvoker" uiAccess="false"
UAC Elevation Level: Standard User or Disabled
==============================

[Deana]

Well it appears that the script is successfully executing up to the TimeYmdHms( ) line. What is the very next line in the script? That is most likely the cause of the script unceremoniously ending.

[MW4]

Now = TimeYmdHms( )
Midnight = StrCat(StrSub(Now,1,11), "00:00:00")
Seconds = TimeDiffSecs(Now, Midnight)

if seconds > 79200 ; is it after 10pm? wait till midnight
   timedelay( 86640 - seconds )
endif

[Deana]

Strange I wouldn't expect StrCat or StrSub to crash.

I noticed the script is located on a y: drive.

Code: [Select]

Y:\Users\WBT\Automated\Status.exe

I wonder if that mapped drive is getting torn down and the EXE is losing the connection to the WIL DLL. What happens if you copy the EXE file and run it locally? Do you still have a problem?

[MW4]

I compile using large exe, so they come with it

[td]

Compiling with the large exe option would not remove the possibility of the problem Deana mentioned.  In fact, it makes it more likely the cause.  Windows 7 has been around for over 4 years, is the most commonly used version of Windows, and the two functions you are using are two of the most commonly used functions in WIL.  If there was a problem with either of those functions specific to Windows 7, we would have known about it a long time ago.

[MW4]

Actually I think my issue is related to UAC and the code saving temp logs to my c:\, I think the error gets thrown later which causes the stop at the Now = TimeYmdHms( ).
I have remapped those from C:\to a normal folder and am in the process of testing.

I'm not exactly sure of what is mean't by the mapped drive getting torn down...the only thing that is on the mapped drive is the exe itself, all internal code is mapped via UNC.
Would saving the path to the EXE on the Y:\ drive as a UNC make a difference in the "torn down" scenario?

[Deana]

Actually I think my issue is related to UAC and the code saving temp logs to my c:\, I think the error gets thrown later which causes the stop at the Now = TimeYmdHms( ).
I have remapped those from C:\to a normal folder and am in the process of testing.

I'm not exactly sure of what is mean't by the mapped drive getting torn down...the only thing that is on the mapped drive is the exe itself, all internal code is mapped via UNC.
Would saving the path to the EXE on the Y:\ drive as a UNC make a difference in the "torn down" scenario?

You are correct that UAC disallows all users from creating files in the C root directory, an error message like “A required privilege is not held by the client” or “access is denied” will be prompted.

A dropped mapped drive would cause the compiled EXE to lose access to its own dll which would cause the EXE to crash.

A complete DebugTrace is in order. ( A lot of assumptions have been made due to lack of information).  Are you getting a WinBatch Error or is the script crashing? Again please provide the complete trace file output.

[MW4]

that's what is the problem...very little in the debugtrace, and zero info regarding the error at the win7 level other than  "xxx has stop working"

Does my:
  ErrorMode: @CANCEL
have anything to do with it?

In XP I would get an offending line in the WBT EXE

[Deana]

that's what is the problem...very little in the debugtrace, and zero info regarding the error at the win7 level other than  "xxx has stop working"

Does my:
  ErrorMode: @CANCEL
have anything to do with it?

In XP I would get an offending line in the WBT EXE

Actually no that is default error handling state. ErrorMode: @OFF would be a potential problem. Please read: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch+Two~Minute~Lecture~on~ErrorMode~No-Nos.txt

Again, I recommend checking if running the code on a local (NON NETWORK drive) resolves the issue.