Member Avatar for rmaadil

I have created an application in C++ using MFC, and then one day I have executed this application using Intel VTunes just to monitor the performance of the application and to check where most of the time is consumed by my application. After analyzing I have found that about 40% of the time is consumed by my code and around 35% of the time is consumed by the ntdll.dll file. So, the point here I wants to know is that is this a normal behaviour. I mean is this consumption i.e. 35% of the total time justifiable. Can anyone tell me that which kind of responsibilities resides on ntdll.dll i.e which kind of functionalities is achieved through this dll file, so that I can sort things out in my case and be able to optimize the code.

  • 3 Contributors
  • 4 Replies
  • 136 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by jbennet

Dani AI

Generated

Context: reported ~35% of CPU samples attributed to ntdll.dll after profiling an MFC app (Pervasive SQL + SQL Server) with Intel VTune. Short answer: that percentage is not necessarily a bug. Time in ntdll usually means samples were taken while code was in low‑level runtime stubs, syscall boundaries, heap/CRT helpers, synchronization waits, or other user‑mode primitives that delegate work to the kernel. VTune will often collapse many frames under the module name when symbols/unwinding are incomplete.

Concrete next steps to pinpoint the real hotspot:

  • Re-run VTune with full call stacks and enable frame‑pointer or stack‑unwinding options so you get the caller chain above ntdll.
  • Configure Microsoft public symbols so ntdll frames resolve to meaningful function names (example for a cmd session):
set _NT_SYMBOL_PATH=srv*c:\symbols*http://msdl.microsoft.com/download/symbols
  • Use Process Explorer or xperf/WPR + WPA to collect ETW traces and inspect thread stacks and CPU usage over time.

What to look for and how to act:

  • If you see NtWaitForSingleObject / WaitForSingleObject dominating, threads are blocked. Move long ops off the UI thread, use a thread pool, or use async I/O.
  • If RtlAllocateHeap / heap allocs dominate, reduce small/frequent allocations, use object pools, or a custom allocator for hot paths.
  • If NtReadFile/NtWriteFile or network/syscall names appear, batch operations, enable async/overlapped I/O, and tune driver/client settings (ODBC/ADO pooling, bulk fetch).
  • If many LdrLoadDll or dynamic loads appear, avoid repeated loads at runtime.

Quick checklist: enable symbols, capture stacks, identify specific ntdll functions, trace back into your code or the DB client DLLs, then target the root cause (waiting, I/O, heap, or load-time cost). This approach will tell whether the 35% is expected overhead or something you can optimize.

Recommended Answers

All 4 Replies

Member Avatar for Kraai

The ntdll.dll file is a file created by Microsoft that has a description of "NT Layer DLL" and is the file that contains NT kernel functions.

Member Avatar for rmaadil

Can you please elaborate a bit more. In my application (MFC based and there is interaction with databases (Pervasive SQL and SQL Server)), which process will be using the ntdll.dll file etc.

Member Avatar for Kraai

It depends, if your application is using any kernel functions it may interact with ntdll. You have an executable application, so does it link to any DLL?

Member Avatar for jbennet

NTDLL gets used by IE. If you use IE components in your MFC app it will call it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.