3

My machine at work has recently been updated to Windows 10, from Windows 7, and it has become incredibly slow. The IT has installed a bunch of new tools for security and protection after the upgrade but they are saying the problem is not with their tools. I have been trying to figure out what is going on. I am not the only engineer who has having this problem and almost all Windows 10 users are experiencing this issue.

I started monitoring some of the installed programs using API Monitor and I have noticed that any system call related to disk I/O is taking a really long time to return. I capture a run of the application and then parse the summary and try to find the hottest API calls.

I monitored the program that I myself am developing and the following API calls take around 70% of the total time:

  • _wopen
  • CreateFileA
  • fgets
  • ReadFile

I assumed it might be a disk related issue but in safe mode everything works as expected and feels snappy. I tested the same app in safe mode and the above API calls are still the hottest calls but they barely make 5% of the total running time. This makes me believe the problem is not disk but rather some other installed service on my machine that monitors all disk I/O related API calls and makes my machine so slow. However I don't know which application is interfering with the API calls.

How can I find why a specific API call is taking so much time? Can I step into windows kernel and debug this issue?

I hope this is the right place for this post.

Improve this question
3
  • 1
    You can always use a tool like xperf to dig down into what's slowing down your system. In general the upgraded systems also seemed slower for me, although newly installed Windows 10 installations weren't affected. Debugging or reverse engineering is probably not of any help. Timing in a debugger, for example, will be completely skewed. So how do you expect to judge the speed? You may want to read on the RandomAscii blog or get a book on performance analysis on Windows. The on-board (and free-of-charge) Microsoft tools have only gotten better since Windows 7.
    – 0xC0000022L ♦
    Jul 13, 2018 at 11:00
  • @0xC0000022L I think there is a misunderstanding here. I did not use a debugger at all. I just used the API monitor tool to track which Windows API functions are being called. The tools is essentially like strace for Linux. It times every syscall. Now, what I am trying to figure out is why these windows API calls are slow. I am experiencing the same issue with all programs and not just my custom program.
    – Ali
    Jul 16, 2018 at 3:57
  • while I may have misunderstood the part about the debugger, I think you can still get a lot of insight from those tools I mention. Igor even wrote up an answer and pointed directly to what I meant.
    – 0xC0000022L ♦
    Jul 17, 2018 at 8:46

1 Answer 1

Reset to default
1

Windows applications do not work in isolation. They have to share the processor with all the other processes, services, drivers and so on. There may be a myriad reasons why a specific API call is slow, and it's quite unlikely the API itself is a problem. Especially with I/O, there are all the caches, drivers, and hardware itself (i.e. HDD/SSD) to consider. To get a global picture you can use something like already-mentioned xperf, Windows' own Performance monitor, or possibly the nice UIforETW GUI wrapper around them.

Here is a good starting point for investigating Windows performance issues using ETW: https://randomascii.wordpress.com/2015/09/24/etw-central/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.