Invoke PowerShell/Start Process: Backslashes get Added to String at Runtime

[Jack_Moran]

Here is the String in question, used in the Invoke PowerShell activity to make a PowerShell script:
String.Format("wevtutil epl {0} {1}\Data\Output\{4}-eventviewer.evtx ""/q:*[System[TimeCreated[@SystemTime>='{2}{3}' and @SystemTime<'{4}{5}'] and (Level={6})]]""", in_Config("LogType").ToString, IO.Directory.GetCurrentDirectory.ToString, in_Config("StartDate").ToString, in_Config("StartTime").ToString, in_Config("EndDate").ToString, in_Config("EndTime").ToString,in_Config("LogLevel").ToString)

Here is an example of how this String should come out:
wevtutil epl Application C:\Users\moranj\Downloads\WindowsLogExtract\Data\Output\2023-01-31-eventviewer.evtx "/q:*[System[TimeCreated[@SystemTime>='2023-01-29T00:00:00' and @SystemTime<'2023-01-29T00:00:00'] and (Level=2)]]"

However, once the program is running, both the String with Config values and the example String get backslashes added to them out of nowhere! Observe the Locals value below:

Using the Start Process activity instead yields the same result. The main problem is the backslash that gets added before the first set of double quotes, though it is worth noting that another backslash gets unexpectedly added at the end. What is causing this to happen?

[Anil_G (Anil Gorthi)]

@Jack_Moran

Thats is added as an escape character for the double quotes you have…it is how it shows…did you try printing it and chekc the log message?

Cheers

[Jack_Moran]

I did, and the Log Message is able to print it as intended:

[Anil_G (Anil Gorthi)]

@Jack_Moran

In locas just for visibility or in the backend it adds that backslash as an escape character…it is not actually added…as you added double double wuotes to escape …when it saves to eacape it adds a balckshash…hope this is clear

If you are facing any issue then please check what is wrong with the details

Cheers

[Jack_Moran]

The issue that occurs is that the wevtutil command fails to extract all of the logs specified. In the example I provided, the resulting evtx file should extract all three error logs that exist within that time frame… however, it only extracts one of them. What are your thoughts on this?

[Anil_G (Anil Gorthi)]

@Jack_Moran

Just to confirm when you execute this in powershell are you getting 3? Because as per query i dont see any issue

If not then may be in the time frame there is only one log with level 2 …

If you dont want a level filter you can set that to 0

Cheers

[Jack_Moran]

No, using Invoke PowerShell I am only getting one. But when I apply the same conditions in Event Viewer myself, I get 3. Does this mean the activity itself has an issue?

[Anil_G (Anil Gorthi)]

@Jack_Moran

getting

@Jack_Moran

The activity does not have an issue but the power shell script you wrote might have a issue or may be we are filtering out the records some how…if in power shell you are getting 1 then in UiPath also you will get only one

cheers

[Jack_Moran]

Perhaps it could be an issue with the properties? Here they are:

[Anil_G (Anil Gorthi)]

@Jack_Moran

If that is the case then from
Power shell why are you getting 1?

Cheers

[Jack_Moran]

Very true… looks like it wouldn’t be an issue with the properties after all. This likely confirms that my PowerShell script itself is erroneous in some unforeseen way. Thank you for helping me figure this out! I will take this issue to Stack Overflow since this has become a PowerShell specific problem.

[Anil_G (Anil Gorthi)]

@Jack_Moran

Please feel free to close this topic as needed

Happy Automation and let me as well check if I can give you some script changes

Cheers

[Jack_Moran]

If you have the knowledge for it, any script recommendations would be much appreciated! I will keep the topic open just in case you are able to come up with something.

[Jack_Moran]

With the help of @Anil_G I have found the answer: As he mentions below, the backslashes don’t actually do anything; they are just UiPath’s way of processing my String. The actual issue was the command itself: I had failed to account for time zones! This is why my extracted logs, and the logs I was seeing in Event Viewer for the same time period, did not match up. The above command is still correct, but you must specify to your end user that their input should be in UTC time, NOT your timezone.