07-07-2010 03:16 AM - edited 07-07-2010 03:19 AM
I get error 1097 when calling NtSetTimerResolution in NTDLL.DLL. Why ? I've scoured most posts on this forum describing error 1097 and tried suggested solutions to no avail.
This is a link to the function protoype (copied below) which I matched in the Call Library node of the attached vi (you will be prompted to locate NTDLL.DLL on your system when opening it)
NtSetTimerResolution and NtQueryTimerResolution are defined as follows. All times are specifified in hundreds of nanoseconds.
NTSTATUS NtSetTimerResolution (
IN ULONG RequestedResolution,
IN BOOLEAN Set,
OUT PULONG ActualResolution
);
Parameters
RequestedResolution
The desired timer resolution. Must be within the legal range of system timer values supported by NT. On standard x86 systems this is 1-10 milliseconds. Values that are within the acceptable range are rounded to the next highest millisecond boundary by the standard x86 HAL. This parameter is ignored if the Set parameter is FALSE.
Set
This is TRUE if a new timer resolution is being requested, and FALSE if the application is indicating it no longer needs a previously implemented resolution.
ActualResolution
The timer resolution in effect after the call is returned in this parameter.
Solved! Go to Solution.
07-07-2010 10:55 AM
It wasn't clear from the prototype you referenced, but in some other places I googled, it looks like NTSTATUS is supposed to be an int. But I don't think that is really the problem. I think the real problem is that this .dll wants stdcall (WINAPI) instead of C calling convention. At least it seems to succeed if I make this one change to your example VI. I didn't test if it actually changes anything about the timing system, though.
Best Wishes,
Matt
07-07-2010 06:17 PM
Thanks for your suggestion Matt. I'm suprised you got it to work as I had already tried your suggestion of selecting stdcall (WINAPI) instead of C calling convention (and did again after reading your reply) but I still get error 1097 !
rgds
07-07-2010 06:58 PM
Woohoo ! I solved the problem.
I was using a copy of NTDLL.DLL from here C:\Drivers\I386\SYSTEM32\NTDLL.DLL (version 5.1.2600.1106)
instead of here C:\WINDOWS\system32\ntdll.dll (version 5.1.2600.5755).
A rather interesting side observation I made, when I tried placing the older version into C:\WINDOWS\system32 to see if it was just a dependency issue rather than a version issue, I couldn't do it ! I tried renaming C:\WINDOWS\system32\ntdll.dll to C:\WINDOWS\system32\ntdll.dll.old, and straight away a replacement C:\WINDOWS\system32\ntdll.dll would pop up in its place !! I even tried dragging and dropping C:\Drivers\I386\SYSTEM32\NTDLL.DLL to C:\WINDOWS\system32\ntdll.dll , it seemed to replace it but some security system immediately overwrote it with the latest version. Either WinXP is smarter than I thought or perhaps something like Microsoft Windows Defender Antispyware installed by our company is doing this.
Anyway I confirmed the lateer version is needed because when I copied C:\WINDOWS\system32\ntdll.dll to C:\Drivers\I386\SYSTEM32\NTDLL.DLL it also solved the problem.
You might well ask why I didn't use the correct version in the first place - well not knowing where it was located, I only noticed the older version when I searched for it with my Google Desktop.
rgds