4

I want to monitor all running processes and if there is some relevant process for me (determined by file path), doing some logic which include getting StartDate. Problem is that some processes give me "Access denied" Win32Exception during accessing StartDate property. I wounder if I can determine if I have access to process before trying accessing process StartDate, since exception handling could take some noticeable delay especially when there are a lot of processes running.

So question is: Is there any way to do something like Process.HasAccess(process) check without dealing with exceptions?

VVN
  • 1,607
  • 2
  • 16
  • 25
Amadare42
  • 415
  • 3
  • 14
  • You get the Access Denied in response to what exactly? – 500 - Internal Server Error Mar 06 '16 at 01:07
  • When trying to access DateTime property. – Amadare42 Mar 06 '16 at 11:37
  • *"Noticeable delay"* with exception handling means: Milliseconds, at most. You'd have to have **lots** of exceptions to even notice. – IInspectable Mar 07 '16 at 17:26
  • 1
    Better to ask forgiveness than permission – David Heffernan Mar 07 '16 at 20:52
  • @IInspectable Looping through all running processes and using exception handling to check Process.StartTime takes over 2 seconds. Doing a WMI query only 20ms. Try/catch literally 100 times slower. – Sean O'Neil Dec 04 '19 at 13:43
  • @sea: Have you profiled your code and can unambiguously subscribe the 100x slowdown to exception handling alone? – IInspectable Dec 04 '19 at 15:21
  • @IInspectable [See for yourself](https://dotnetfiddle.net/UKuTdj). Don't run the fiddle obviously, just try it on real PC, new Core 3.0 console app, add System.Management via NuGet. – Sean O'Neil Dec 04 '19 at 23:47
  • @sea: I was commenting strictly on the cost of exception handling. Your benchmark does neither confirms nor refutes that. A benchmark is not profiling. Certainly I wasn't questioning, that calling a native implementation (such as WMI) gives you native performance, that's generally faster than managed library code executing on the .NET runtime. – IInspectable Dec 05 '19 at 10:42
  • @IInspectable You're right, comparing managed to native proves little. I don't have profiling set up here. But [look](https://dotnetfiddle.net/7SVI2R). Just run that fiddle and then tell me exception handling isn't crazy expensive in some scenarios. – Sean O'Neil Dec 05 '19 at 12:29
  • @sea: This isn't going to lead anywhere. What's the basis for you subscribing the entire performance difference to exception handling? Either provide evidence, or just resist prolonging a discussion, that's not going to help anyone. – IInspectable Dec 05 '19 at 13:10
  • @IInspectable I just did provide evidence. Did you not see the new link? How is that not concrete proof? Other than the exception both loops are identical and do nothing but add a number. – Sean O'Neil Dec 05 '19 at 13:26
  • @sea: You are comparing *completely* and *utterly* different code, and then jump to the conclusion, that the difference in runtime behavior is solely due to exception handling. That's not proof. That's not even evidence. That's not even comparing apples to oranges. – IInspectable Dec 05 '19 at 13:41
  • I wasn't comparing them, I was showing proof that an exception causes a hit all by itself. You want to go back to this use case, [I already tested two loops](https://dotnetfiddle.net/KCaCkk) each checking for Process.StartTime, no WMI. First had all procs with full access, the other procs with limited access. 100x difference. – Sean O'Neil Dec 05 '19 at 14:01
  • A single Proccess object with limited access actual throws 25 different exceptions, and a Win10 machine has around 100 of these processes. So checking for StartTime with try/catch is a very bad idea. There's nothing mysterious about this use case. The exceptions slow it to a crawl. 100 x 25, now loop through 3 times because you want to identify child processes. 2-3 second delay in a synchronous operation, and if you want to set up a polling timer, out of the question. "Noticeable delay" with exception handling means: Milliseconds, at most: false statement in this scenario. That is all. – Sean O'Neil Dec 05 '19 at 14:04
  • @sea: So I was wrong. The cost is not *"milliseconds"*, but *"microseconds"*. For exception handling. That makes my initial comment all the more right: There is no noticeable delay in using exception handling. As for your math: That's all wrong. The cost does not scale linearly with code size. It adds a *constant*. So 100 times microseconds is still under a millisecond. Is that a *"noticeable delay"*? – IInspectable Dec 05 '19 at 14:07
  • Besides, benchmarking is hard. Your second (third?) benchmark is misleading. It's comparing a cold code path against a hot code path. Results are meaningless. – IInspectable Dec 05 '19 at 14:10
  • Feel free to chime in [here](https://stackoverflow.com/questions/891217/how-expensive-are-exceptions-in-c). – Sean O'Neil Dec 10 '19 at 14:56
  • I just stumbled upon the same issue trying to access those fields of a Process object. There is a notable difference between objects that do not throw the access denied exception. Especially if the exception is thrown by 100+ objects... – eKKiM Jul 12 '23 at 20:12

0 Answers0