• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 291
  • Last Modified:

Why would I only occasionally get "entry point not found" in a dll?!?


  This question got no replies so I am trying again, here in the general programming section.

  Cutting to the chase: the application WORKS - and successfully calls the various functions in a system DLL. However, about once a day I get the "entry point not found error" - for a call that works most of the time.

  Yes - I know the error usually means that the function I am calling is not in the DLL. However - I know the call is working most of the time.

  Why would a DLL call only occasionally fail resulting in "entry point not found"?

  I verified the version of the DLL, even copied it to the application directory in an attempt to make sure which version is being used.

  Thanks for your help guys, this is driving me nuts!
0
RPannett
Asked:
RPannett
  • 6
  • 6
1 Solution
 
jrs_50Commented:
Just some thoughts given the limited information provided:

If the particular function in question takes parameters/arguments and it is working most of the time but occassionally failing I would presume that the 'not found' is being generated as a default result but one or more of the parameters is incorrect.  For example; perhaps one of the parameters is a counter that eventually restarts/wraps to 0, or under some particular condition a parameter is missing from the call.  The function chokes, resulting in a error, and the error handling doesn't interpret the problem correctly but knows there was a problem.  Result: Not found is the final message that can be reported and is used as a catch-all.

Possible that there is a time-out of some sort and under conditions of certain loads the system can't get to the dll, or possibly a response from it, within the designated time.  The "Not Found" in this instance is still a little deceiving but does make some sort of sense.  It wasn't found because it couldn't get to it.

Possible is a conflict between dll signatures/addressing of some sort.  For example; an older and a newer version of the dll where a particular function is missing from the older dll while the other functions are fine.  Example; most times the sequence of execution results in the new dll being loaded and everythings fine.  Occassionally the sequence of execution results in the old dll being loaded.  Both cases are satisfied that the dll is there, and available, but in the latter case the Not Found occurs.

Is there any relevant detail related to the error?  Is there a debug/dump option that can be performed when the error occurs?  Is it your code and you could add in some temporary handling/reporting from your code when the error occurs so that you could acquire a better sense of what was actually going on at the time of error?   Without something like that I suspect that finding the problem will be difficult.
0
 
RPannettAuthor Commented:

Thanks so much for a quick response. Now I'll give some more detail:

The call that is failing is SetTimer() in user32.dll. (See below for signature..)

The application is written in VB6 (so my debug/dump options are limited to VB6's poor runtime debugging support).

I did find multiple versions of user32.dll, but they were in "patch" directories. Just in case, I copied the windows\system32 version to the application directory.

The VB6 signature for SetTimer() is:

Declare Function SetTimer Lib "user32" (ByVal hWnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerProc As Long) As Long

Following your advice above, I will try and double-check my calling parameters in code prior to calling SetTimer()...and if it fails, log what calling parameters I used.

Any other advice? Sorry I had to post this here, but I got zero responses under the VB forum (my guess is this question looked too much like PAQ's).

0
 
RPannettAuthor Commented:

  More information: the core VB6 application is creating individual Activex/COM .DLL objects (VB6-style multi-threading) based on the classic Microsoft "Coffee" example.  

 It is the "child" COM object that occasionally fails to call SetTimer() in user32.dll.

 I limit the number of threads to 50, I think.

 Thanks again!

0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jrs_50Commented:
I don't have the time to get to the nitty-gritty and I'm neither a VB expert or particularly familiar with user32.  Offhand; I'd be suspicious of the uElapse value as a starting point.  Can it, for example, occassionally go negative as the result of a clock resynch of some sort?

Good luck.  Perhaps others more knowledgeable with the specifics can respond.  You might also want to do a search of MS KB regarding user32 and/or the function.  It might yield some clues.
 
0
 
RPannettAuthor Commented:

  I checked into SetTimer in user32.dll - it's supposed to return 0 if it fails.

  If the call is failing and the "wrong" error is being returned as you say in one of your suggestions, VB is "catching" an error instead of the function returning 0.

  Note that the only reason why the call could fail that I can tell, is if there aren't any timers available for the system to allocate.

  I'm going to just add some error handling, try 2 or 3 times to make the call, and see what happens.
0
 
jrs_50Commented:
As I indicated I'm basically 'guessing' based upon your posts.  Not familiar with coffee example.

Could it be some dll routine that settimer itself is attempting to call and that THAT dll 'cannot be found'?

Some other possibilities:
Could it be that you are running out of threads/timers?  
What happens in the child if the settimer does return 0?
What happens in the parent if the child misbehaves?
Could it be that the error handling is 'off-stack' and picking up an error event that doesn't really belong to it?

Basically; you should a) view settimer's actions based upon various 'what if's' and the things it will call do?and b) work back up the child-parent relationship.

The 'sporadic' nature of the problem SEEMS to indicate that there is a 'particular' situation that causes the failure.  That sporadic nature also dictates that the specific problem will be difficult to pinpoint.  Worse; it is still possible that something entirely different is actually occurring within Windows and then manifesting itself as the sporadic failure that you are seeing.  It would not be the first time Windows hiccoughed in an odd manner.
 
0
 
RPannettAuthor Commented:

  Good advice. Wish I had written this AFTER .NET, since VB didn't really have multi-threaded support. (The Microsoft "coffee" example basically shows how to use COM objects to create threads.)  

  I've modified the application to check and report when SetTimer fails (instead of hopefully crashing), retry a few times with a 1 second pause in between each retry, then give up and return an error. (The parent application will be notified instead of just catching an error.)

  I'll install this version next time the production one crashes to see if the "retry" helps; for instance if I really am running out of timers and just need to wait a second before trying to get another timer.  I may have to go over the code that kills timers to make sure that is working properly.

  Unfortunately, since the error is being misreported by windows, it's hard to tell if I am running out of timers, etc. :-)
0
 
RPannettAuthor Commented:
Ok - the application FINALLY crashed again (same error), so I installed my fix. We'll see if the retry helps, or if I get more information..if I figure this out because of your advice I'll reward you the points in a day or two!
0
 
jrs_50Commented:
Good luck.  I know it's a bit like looking for the needle in the haystack.  It CAN be found because it IS there but...

You asked the question !!  :-)

0
 
jrs_50Commented:
Thank you very much for the points.  I hope that you did, in fact, find/fix the problem.
0
 
RPannettAuthor Commented:
Oops - thought I had posted a comment: The problem did not return but I have not gotten any indication of WHAT I fixed. Basically I think that the small changes I made (retry, etc.) somehow prevented a "bad" call from occurring to SetTimer(). If my "retry" was happening I SHOULD be seeing that in some debugging information. So, evidently something I did (from your advice) fixed it!
0
 
jrs_50Commented:
LOL - sometimes the 'fixes' are as mysterious as the 'problems'.  

My guess would be either a) you actually fixed the problem or b) the changes you made altered the 'timing' of processing sufficiently to adjust the overall load such that the problem has not, yet, reoccurred.

Good luck!

Thanks again.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now