Link to home
Start Free TrialLog in
Avatar of PMH4514
PMH4514

asked on

Procedure entry point GetTickCount64 could not be loaded in KERNEL32.DLL

Hello,

I have an application built with Visual Studio 2010 which we normally run on 32-bit Win7.

I am attempting to run the software on a 32bit Windows XP.. Immediately upon launch attempt, I get an Entry Point Not Found error, "The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.DLL."

This 32bit XP machine is actually a  VM running under Oracle VirtualBox on a 64bit Win8 host, though I'm not sure how relevant that is.

My first thought was to install the Visual Studio 2010 redistributal on the XP machine, however I then learned that it was already present.

I looked through all the code for the application, and while GetTickCount is called, GetTickCount64 is never called, so where is this coming from and is there anything I can do to make it work? (Updating the target system to Win7 is difficult at best)

I ran "Dependency Walker" on the EXE and do see the following which is likely relevant, but I'm unsure how to properly handle it:

IESHIMS.DLL - Error Opening File
WER.DLL Error opening the file.



Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Avatar of jkr
jkr
Flag of Germany image

Any code referencing this function will not work on XP, see 'GetTickCount64()' (http://msdn.microsoft.com/en-us/library/ms724411%28v=VS.85%29.aspx) on MSDN:

Minimum supported client
      Windows Vista

As a workaround, try either 'GetTickCount()' (http://msdn.microsoft.com/en-us/library/ms724408(v=vs.85).aspx) or load that entry point dynamically, e.g.

typedef ULONGLONG WINAPI (*FPTR_GetTickCount64)(void);

ULONGLONG ullCount;

FPTR_GetTickCount64 pGetTickCount64 = (FPTR_GetTickCount64) GetProcAddress(GetModuleHandle("kernel.dll"),"GetTickCount64");

if (pGetTickCount64) {

  ullCount = (*pGetTickCount64)();

} else {

  ullCount = GetTickCount();
}

Open in new window

Avatar of PMH4514
PMH4514

ASKER

Hi JKR, thanks.. But that's the thing, none of my code is using GetTickCount64 anywhere..
>>I looked through all the code for the application, and while GetTickCount is called,
>>GetTickCount64 is never called

Sorry, missed that part - try setting your _WIN32_WINNT value to match XP when compiling, e.g. like

#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x500 // XP
#endif
#include <windows.h> // will now omit 'GetTickCount64()' and be compatible with XP

Open in new window


See also http://msdn.microsoft.com/en-us/library/6sehtctf.aspx ("Modifying WINVER and _WIN32_WINNT")
Avatar of PMH4514

ASKER

Thanks I'll give that a try shortly..
Avatar of PMH4514

ASKER

with #include <windows.h> I can't compile
(afxv_w32.h) reports #error WINDOWS.H already included. MFC apps must not #include <windows.h>

Without that line, I can compile, but on XP it still shows me the same error about GetTickCount64. Did you mean to say "0x0501" for XP? (the link you supplied says that)
Avatar of PMH4514

ASKER

an aside, I tried creating a basic new MFC project in VS2010.. No code, just the basic project with the OK/cancel, compiled in release mode and it runs on my Win7 box. I tried running it on the XP box, and I get a failed to start because MSVCR100D.DLL is missing..   I then added the same linker settings from my real app to this sample app,  and it again gave me the MSVCR100D.DLL missing error (though nothing about GetTickCount64, thinking maybe it was used in a linked library)

I installed the VS2010 redist on the XP system, no luck.. even more odd, MSVCR100D.DLL doesn't exist anywhere on the Win7 box I used to compile this test app (I do see MSVCR90.DLL)... is this indicative of anything?
Ah, OK, That was meant to be put before you #include <windows.h> - in case of a MFC app, set that in your project settings, i.e. ALT+F7, then "Configuration Properties|C/C++|Perprocessor|Preprocessor Definitions". If _WIN32_WINNT is present already, chenge the value, if not, add it.
Avatar of PMH4514

ASKER

It is not present. So simply change the list of Preprocessor Definitions from:
NDEBUG
WIN32
_WINDOWS
UNICODE

to
NDEBUG
WIN32
_WINDOWS
UNICODE
_WIN32_WINNT=0X500
?

I'll go try that.. Also my XP system has the .NET framework 3.5, perhaps it needs to be updated or is that definitely not related?
Yes, just like that. Use a small 'x' though and be sure to do that for both the Debug and the Release build. And indeed, unless you are using CLR, the .NET version is completely unrelated.
Avatar of PMH4514

ASKER

weird, it still throws that GetTickCount64 error immediately on launch..
Did you do a "Rebuild all"?
Avatar of PMH4514

ASKER

yes, clean and rebuild all.

but, I just found, I have another small "utility" EXE that goes in the main application runtime folder.. It too was built with VS2010 C++  and considerably smaller in scope..  It throws exactly the same GetTickCount64 error on startup, and it doesn't either use that call.  BUT, both of these EXEs link to a third-party DLL that just might be using it (and both, for this custom XP install, do not need it. ) So I'll dig a bit unless you can think of anything else.
ASKER CERTIFIED SOLUTION
Avatar of jkr
jkr
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of PMH4514

ASKER

and there it is!
Ok at least this gives me next steps.. Tomorrow I'm going to make a conditional compile that prevents this DLL from linking, as I said its functions aren't required in this "custom" build I'm making for the lonely XP customer.  Hopefully that gets me through it I'll post back. Thanks again
Avatar of PMH4514

ASKER

success! a conditional build lacking the offending library solved the particular problem.. still gonna push for a Win7 upgrade though !
While I do understand that it's nice to work with W7, maintaining backwards compatibility with XP never is a bad idea - might save you work at some point...