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

entry point __lc_collate_cp problem

I have an application that throws the following error when it is run on WinNT4 (SP6a) box.

"The procedure entry point __lc_collate_cp could not be located in the dynamic link library MSVCRT.dll"

I know that this issue is related to older version of MSVCRT.dll in System32 folder. And if I replace it with newer version, this error goes away.

The information that I am looking for...

1. What API or part of SDK triggered the use of this entry point.
2. Is there a workaround meaning that I remove some calls from app so that I don't have to use the newer DLL.

Please don't answer with comments "why don't you want to replace the old DLL?". Bottom line is replacing the older DLL is not an option because it requires a restart or server. And we can't afford that.

VC6.0 (SP5)
WinNT 4
MFC (SDI) App

Naveen
0
naveenkohli
Asked:
naveenkohli
  • 8
  • 6
1 Solution
 
AlexFMCommented:
Try to place new version of MSVCRT.dll to program startup directory.
0
 
naveenkohliAuthor Commented:
AlexM,
I have already mentioned in my question ..."Replacing the DLL is not an option". And this DLL can't be replaced without restart because OS uses the same DLL.
0
 
jkrCommented:
>>"Replacing the DLL is not an option"

This might be too simple, but: Why don't you link the app statically to the CRT? IOW: Using /ML instead of /MT. In this case, using libc.lib instead of msvcrt.lib, you will be independant of teh msvcrt.dll installed on the machine at the cost of getting a bigger binary image...

0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
naveenkohliAuthor Commented:
jkr,
that might be an option. We really don't care about size of the binary. What I am trying to figure out is, why the app got dependency on this new DLL.
I have been looing at the export of MSVCRT.dll and MSVCp60.dll. And the stuff in MSVCP60.dll is mostly related to STL. And my app does use STL heavily. Can this be the reason of this dependeny? Inthat case I may have to remove STL from the app altogether.
let me give it a try and i will be back...
0
 
jkrCommented:
STL should not be an issue - '__lc_collate_cp' is declared in 'setlocal.h'
0
 
naveenkohliAuthor Commented:
Static linking hasn't helped so far...
0
 
naveenkohliAuthor Commented:
Now I have got link errors...

unresolves external symbol __endthreadex
unresolves external symbol __beginthreadex

If I switch to /ML that mean i will be using Single threaded libs. And I have bunch of worker threads getting spawned in  my app. Will this setting affect the threads I have.
0
 
jkrCommented:
Yikes, I meant from /MD to /MT of course...
0
 
naveenkohliAuthor Commented:
Infact thats the first thing I did.. that did not help either.
0
 
naveenkohliAuthor Commented:
My bad... I have one DLL which was using dynamically linking to CRT. After recompiling that DLL with static linking, everything worked ok with static linking.

thanks....
0
 
jkrCommented:
Thanx :o)

You are welcome...
0
 
naveenkohliAuthor Commented:
jkr,
Now the app has become pretty unstable. The static linkin has introdcued the trouble with memory allocation and freeing with STL containers. I am getting crashes in new/delete operators all over the place. All projects are using /MT link switch now. Is there anything that needs to be done for STL containers. A lot of APIs reutrn list objects.
0
 
jkrCommented:
>>The static linkin has introdcued the trouble with memory allocation and freeing with STL containers

Are you passing memory over module boudaries (i.e. allocating in one DLL and freeing in another)?
0
 
naveenkohliAuthor Commented:
I am afraid thats what is happening. The app was using Dynamic linking and this was not a problem. Is there is a quick fix to this problem or i have to modify the code so that memory allocation and freeing happens in the same dll boundary. Currently I am working on fixing this boubdary crossing problem but I was looking into something quick because changing the app is going to take some time.
0
 
jkrCommented:
Well, the problem is that each module now has is own allocator and heap. An idea would be to supply allocators that take care of this. The 'cleaner' way would be to not allocate/free over module boundaries (apart from that being the 'clean' way anyway :o)
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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