|
MSVCP60.DLL contains STL-related classes, like std::string or iostreams.
You basically have two options now:
1) link statically to C runtime
2) create an installer that updates MSVCRT.DLL and MSVCP60.DLL. Note that users will have to reboot after install - these .DLLs are used by Windows itself and can't be simply overwritten.
Oh, and there's one more possibility, but I've never tried this: you can copy correct MSVCRT.DLL and MSVCP60.DLL to your application directory. The Windows loader looks for DLL in app dir first.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
It's right, I used STL in my project and it causes this problem.
I'll use static link in my project to solve this problem because it's not working by copying the 2 DLL in the AP's directory in NT...
Thank u...
|
|
|
|
|
Hello everyone,
I have an application that need to connect to a mapped drive using the CreateFile() function. It ran fine as an application. However when i convert the application to a NT Service, it can't work.
What is the cause for this and how do i solve it?
Any help would be great
Thanks
|
|
|
|
|
What account is the service running as? Mapped drives are specific to one account, so if the service is running as the system account, it doesn't have the drive mappings that you make in your own account. Change the service to run under your account.
--Mike--
http://home.inreach.com/mdunn/
Ford: How would you react if I said that I'm not from Guildford after all, but from a small planet somewhere in the vicinity of Betelguese?
Arthur: I don't know. Why, do you think it's the sort of thing you're likely to say?
|
|
|
|
|
By default all services logs on as the "system" user. This user is different for every NT machine on a network. That's why it only have access to the local machine.
If you want a service to connect to other machines, you should make an account on those machines with the same username and password, or if the machines are in a domain, just make a domain account. When you change the service to log on as that account it should work just fine  (if this user have access the the shared resources, of course)
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Oops, I forgot...
You cannot connect to a mapped drive like "m:" you have to connect to the UNC path like "\\server\share".
I don't know how you map's your drives, but most often it happens with a logonscript, and a service can run without you are logged on. Even if you are logged on it won't work for the service, because it actually runs under another (hidden) desktop than you do...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Hello all,
I have created a dialog type app.. I have a modeless dlg box that needs to run a timer, the reason it's Modeless is the timer needs to be active all the time even when the Dialog box it hidden (I'm checking if the timer is equal to a int every second, when they match I run a event).. I added the WM_TIMER function to this Modeless dialog.. When I fire the "OnTimer(UINT nIDEvent)" by doing a "SetTimer(IDC_S_TIMER1,1000,NULL);" from another control, I get the following error in debug mode:
First-chance exception in Dialog.exe: 0xC00000FD: Stack Overflow.
And it points to OnTimer(UINT nIDEvent)
->{
Any ideas why?
Thanks,
RobJones
|
|
|
|
|
The stack overflow could be caused by recursive calling OnTimer(UINT nIDEvent). How does the call stack look after the exception?
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Sorry, I'm new to programming and I'm not sure what the call stack is.. is this maybe what your talking about:
139: void CAdd1Dlg::OnTimer(UINT nIDEvent)
140: {
00402750 push ebp
00402751 mov ebp,esp
00402753 push 0FFh
00402755 push offset __ehhandler$?OnTimer@CAdd1Dlg@@IAEXI@Z (00551555)
0040275A mov eax,fs:[00000000]
00402760 push eax
00402761 mov dword ptr fs:[0],esp
00402768 sub esp,0B78h
-> 0040276E push ebx
0040276F push esi
00402770 push edi
00402771 push ecx
00402772 lea edi,[ebp-0B84h]
00402778 mov ecx,2DEh
0040277D mov eax,0CCCCCCCCh
00402782 rep stos dword ptr [edi]
00402784 pop ecx
00402785 mov dword ptr [ebp-10h],ecx
141: switch (nIDEvent)
Sorry for my ignorance..
Thanks for your help!
Rob
|
|
|
|
|
Try
inline void CAdd1Dlg::OnTimer(UINT nIDEvent)
|
|
|
|
|
Just tried it and I still get the same error.. 
Thanks for the help though,
Rob
|
|
|
|
|
Hi Rob,
glad to be of assistance.
What you've posted is the disassembly - 10-15 years ago people would actually program writing this mumbo-jumbo! 
Assuming you're using MS VC++, you can see the call stack _when you're debugging_ by pressing alt+7 (or choosing View->Debug windows->Call Stack. You can also see it in the variables window by expanding the combo box at the top of this window, the one labeled "context".
The call stack is a list of all the calls that led to the point in the program where you are right now. This is how the call stack looked i a test program using OnTimer:
CTest10View::OnTimer(unsigned int 1) line 139
CWnd::OnWndMsg(unsigned int 275, unsigned int 1, long 0, long * 0x0012fd10) line 1829
CWnd::WindowProc(unsigned int 275, unsigned int 1, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x00422cf0 {CTest10View hWnd=0x0006031a}, HWND__ * 0x0006031a, unsigned int 275, unsigned int 1, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x0006031a, unsigned int 275, unsigned int 1, long 0) line 368
AfxWndProcBase(HWND__ * 0x0006031a, unsigned int 275, unsigned int 1, long 0) line 220 + 21 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
CWinThread::Run() line 480 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001325f8, int 1) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001325f8, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e87903()
Reading from bottom up you can find the call to WinMain which call AfxWinMain, which called CWinApp::Run() which callled CWinThread::Run() which called GetMessage and DispatchMessage (the USER32! things). Then you can see the trace through the MFC windows procedures (WinProc, AfxCallWndProc, CWnd::WindowProc) and the routing through the message map (CWnd::OnWndMsg and finally CTest10View::OnTimer).
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
The Stack Overflow problem usually arises when you are (unaware) calling the same function several times as fast as you can, until the stack gets full  .
So, what are you doing inside of your OnTimer() function? Could it be possible that you are executing this same function (kind of recursive call, but without an exit condition)?
On the other hand, where are you creating the timer? Could you please show us some of your code to handle the IDC_S_TIMER1 timer's id in your OnTimer() function?
|
|
|
|
|
Sure...
<br />
void CAdd1Dlg::OnTimer(UINT nIDEvent) <br />
{<br />
switch (nIDEvent)<br />
{<br />
case IDC_S_TIMER1:<br />
iS --;<br />
m_ctlTime1.Display(iS,iM,iH,iD,(CString)m_strTime1="%D:%H:%M:%S");<br />
break;<br />
}<br />
<br />
UpdateData(FALSE);<br />
<br />
CAdd1Dlg::OnTimer(nIDEvent);<br />
<br />
<br />
void OnTimerStart();<br />
if(something.....)<br />
{<br />
}<br />
else<br />
{<br />
UpdateData(TRUE);<br />
<br />
iTa = iDa*24*60*60+iHa*60*60+iMa*60+iSa;<br />
iTPDT = iPDTD*24*60*60+iPDTH*60*60+iPDTM*60+iPDTS;<br />
iDiff = iTa-iTPDT;<br />
iS = iDiff;<br />
<br />
strTime.Format("%d",iS);<br />
<br />
SetTimer(IDC_S_TIMER1,1000,NULL);<br />
<br />
m_bStopTime1.EnableWindow(TRUE);<br />
m_bStartTime1.EnableWindow(FALSE);<br />
m_bGrab1.EnableWindow(FALSE);<br />
GetDlgItem(IDC_E_MIN1)->EnableWindow(FALSE);<br />
GetDlgItem(IDC_E_SEC1)->EnableWindow(FALSE);<br />
GetDlgItem(IDC_E_QUANTITY)->EnableWindow(FALSE);<br />
GetDlgItem(IDC_E_MAXBID)->EnableWindow(FALSE);<br />
GetDlgItem(IDC_E_ITEM)->EnableWindow(FALSE);<br />
<br />
fileEditText.Remove(_T("Timestart.txt"));<br />
fileEditText.Remove(_T("TimeUrlstart.txt"));<br />
UpdateData(FALSE);<br />
} <br />
I can only find one section that I do a SetTimer()... The reason I use switch in nIDEvent is because I use to have 2 timere that i would switch between.. I only have 1 now.. I tried to remove the switch and I still get the same error..
Thanks for the help!!!
Rob
|
|
|
|
|
Rob,
It seems that you have some re-entrancy code and a very bad function call. You are calling your function (as I said in my previous message) inside of your function, creating a recursive call with no exit at all. Let me be more specific ...
In your function OnTimer() you have a line at the end that says "CAdd1Dlg::OnTimer(nIDEvent)" and this is the horrible bug. Instead you have to call the base method, i.e. CDialog::OnTimer(nIDEvent).
On the other hand, the timer has been set to signal every one second, and in the code where you are handling this event, there is no way to stop the messaging system sending the signal every one second, and here is where meanwhile you are decrementing your variable and formatting your display, another call has been made and so on.
One good rule is if your timer's handler do a lot of work and the timer's period is short, you have to tell the messaging system "give me a break". So in your code, you can use something like:
void CAdd1Dlg::OnTimer(UINT nIDEvent){
switch (nIDEvent){
case IDC_S_TIMER1:
KillTimer(IDC_S_TIMER1); // Stop the timer
//decrement the count
iS --;
//format and display the count
m_ctlTime1.Display(iS,iM,iH,iD,(CString)m_strTime1="%D:%H:%M:%S");
UpdateData(FALSE);
SetTimer(IDC_S_TIMER1, 1000, NULL); // Restart the timer
break;
}
//UpdateData(FALSE); <=== Make this call before.
//CAdd1Dlg::OnTimer(nIDEvent) <=== OOPS! This is the bad guy in your code
CDialog::OnTimer(nIDEvent); // Use this instead.
}
I hope this helps
Au revoir.
|
|
|
|
|
THANK YOU VERY MUCH!!!
Changing the CAdd1Dlg::OnTimer(nIDEvent) to CDialog::OnTimer(nIDEvent) fixed everything..
Thanks for taking the time to help!
Rob Jones
|
|
|
|
|
Hi A.R.
Your solution to Rob's recursive call problem is of course absolutely correct. However, I don't think Rob's got a re-entrance problem.
>On the other hand, the timer has been set to signal every one second, and in the code where you are handling this event, there is no way to stop the messaging system sending the signal every one second, and here is where meanwhile you are decrementing your variable and formatting your display, another call has been made and so on.
Rob is handling the WM_TIMER message, and while the program is in OnTimer it will not get new messages from the message queue and hence OnTimer will not be called again. Only when Rob returns from OnTimer will a new WM_TIMER message be dispatched. So while a steady stream of WM_TIMER messages will certainly make the application seem unresponsive, it will not lead to any concurrency issues. Furthermore, WM_TIMER messages are handled in a similar manner to WM_PAINT - they are low-priority and will only be handled if the message queue is empty, and multiple WM_TIMER messages in the queue will be merged into one message. And there is no way to find out just how may WM_TIMER messages got zapped. That's why you cannot use timers to make a good clock - you'll have to read the system time inside OnTimer, and cannot rely on exactly 1 second between WM_TIMER messages (not even on average over a period of time). And don't take my word for it - it's all described in Petzold chapter 7.
>One good rule is if your timer's handler do a lot of work and the timer's period is short, you have to tell the messaging system "give me a break".
This is actually very good advice, but only for responsivity-reasons, not for concurrency.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Whenever I try to call DoModal() for a dialog it gets an access violation in LoadResource(...). I tried rebooting thinking my computer was low on resources. No luck. I tried making a new dialog, with no code and calling DoModal() on that one. Same thing happened. I tried the Resourde ID Organizer utility I got from this site. Still no luck.
This just started happening to my project. Other dialogs that I created before today come up fine.
Pleeeeeaaase hellllp meeeeee!!!!!!!!!!!
|
|
|
|
|
It sounds like your resource script has troubles. Have you tried going into the debugger to see what the problem is, and stepping back to see at what stage the function is being called ?
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Never mind.
I am an idiot. I forgot to do AFX_MANAGE_STATE(AfxGetStaticModuleState());
Sorry for bothering you.
|
|
|
|
|
No bother at all. I find often verbalising a problem helps me to find it. FWIW I was not going to suggest that, so I guess I wasn't going to be much help anyhow
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
My app has a console that redirects stdout and stderr, but
apparently it doesn't capture OutputDebugString() messages
or any internal messages from DX8. Is there a way to do it?
Steve The Plant
|
|
|
|
|
To get OutputDebugStrings you'd have to call WaitForDebugEvent. However, this function is apparently designed to be used by debugger running in separate process. I have no idea if this is possible from within the running program itself - this would be a self-debugging configuration
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
With a help of VxD or Kernel Mode Device Driver, you can monitor any messages for debug output. Grab exellent utility at;
http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
Utility looks like single binary but they embedded device drivers for Win9x and NT/Win2k. (They are kind of an alien, not human.)
reiko
|
|
|
|
|
As the other comments stated, you probably want to do it using by debug events.
But since it's in the same app, just blast a new address into the jump table for OutputDebugString (it's in the IMPORT section of your PE (at runtime). If you also wan't to "steal" GetProcAddress() usage you'll have to patch the first few bytes of OutputDebugString() to be a "jmp X", where X is the address of your (stdcall!) replacement function. Either way, you would have to know some IA32 assembly to know what's going on.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
