Why does program act differently from VC++ and if run from command line?
Mechi
I've been dealing with this problem for a while and I was wondering
if
there's anyone out there that can give me some ideas.
I wrote a program that works well (using DirectShow, video etc.).
It's compiled for Release without any optimizations.
When I run the Release version from the Visual C++ (2005)
environment,
all the functions work, everything is OK.
When I double-click the *.exe file from Window's Explorer (also the
Release version), the program works partially. Not all the functions
respond properly.
What would the difference be from running the program in these two
ways? What can cause these differences? Stack size? CPU committed?
Speed?
Thanks for any ideas,
Mechi
Ajay Kalra
It should behave the same. When you run it from IDE, are you passing
any parameters to it? If not, you can run Depends.exe on your
executable at the location you are launching from and make sure all
dependent modules are found. Also, are you using delayed DLL loading
by any chance?
--
Ajay
David Wilkinson
The most common problem with moving from the IDE to Windows Explorere is that
the working directory of the program changes, so you need to be sure you are
using file paths correctly.
GetModuleFileName(NULL, ...) is useful for determining the full path to files
that have a known location relative to the executable.
--
David Wilkinson
Visual C++ MVP
Tom Serface
Do you have any special paths set up in the IDE that you don't have in your
environment (like where DLLs might be located)?
Tom
"Mechi" <mec...@gmail.com> wrote in message
news:fb396205-6266-4208...@a31g2000yqn.googlegroups.com...
Joseph M. Newcomer
source directory; under a double-click of an icon, the working directory tends to be set
to the "My Documents" folder.
Since there is no way for any of us to figure out what "works partially" could possibly
mean, or "Not all functions respond properly", without knowing something about the nature
of the malfunction or what the code is in the "improperly responding" functions might be
doing, there is no way to answer the question.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Ismo Salonen
What do you mean "When I run the Release version from the Visual C++
(2005) environment," ? do you start the program with F5 or Ctrl+F5 ?
The program might get different memory manager when run under debugger
thus memory layout may change. I suspect that you have small bug
somewhere which cause the difference. As it does not manifest as crash
this could be hard to find out. Could you try debug mode build ?
ismo
Mechi
>
> - Show quoted text -
Thanks so much for your answer
.Not passing any parameters - not using DLLs.
See below for more details.
mechi
Mechi
>
> - Show quoted text -
hi!
Thanks for responding!
Under Debug everything works fine. It's obviously a timing problem.
See answer to Joe, above.
Mechi
Mechi
> Web:http://www.flounder.com
> MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text -
>
> - Show quoted text -
Hi Joe!
You're right - you need more details.
I think it may be a DirectShow/COM problem - but i wanted to "hear"
what you MFC experts have to say. All the advice 9about paths, DLLs,
etc was certainly helpful - and i checked them out.
Thanks everyone fo answering.
Now for more detail:
Since I'm using Release mode (in IDE and from explorer) I can't step-
through, so I send some messages to a separate DebugWindow. Also,
this is a Realtime program, so timing is quite important.
The lines of code in question is:
DebugPrint("b4 CoCreateInstance CLSID_Camelot");
hr = CoCreateInstance(CLSID_Camelot1, 0, CLSCTX_INPROC_SERVER,
IID_IBaseFilter, reinterpret_cast<void**>(&pFilter));
DebugPrint("after CoCreateInstance CLSID_Camelot");
In the IDE, this is the output (note the initialization of the camera
when CoCreateInstance is called):
3828819, -> b4 CoCreateInstance CLSID_Camelot
3828826, -> BDR::InitCamera
3828832, -> GetCameraCapabilities
3830721, -> after CoCreateInstance CLSID_Camelot
3830722, -> GetCamCaps in
3830722, -> GetCameraCaps in
3830723, -> GetCameraCaps have m_iSensor <-- succeeded in
accessing camera, sensor
While when double-clicking the *.exe file from the explorer:
4050586, -> b4 CoCreateInstance CLSID_Camelot
4050589, -> after CoCreateInstance CLSID_Camelot
4050589, -> GetCamCaps in
4050590, -> GetCameraCaps in
4050591, -> GetCameraCaps - no m_pCamera - call Init!! <----
didnt succeed in accessing camera, pointers are NULL
Note - only 3msec passed from before until after the call. This is a
definite problem - since the camera is getting accessed, messages are
sent back and forth on the USB - it definitely takes time.
I have no idea how to enter the CoCreateinstance function - what is
happening inside, why from the IDE are the correct dll/ax functions
getting called, while from the explorer they are not.
I've checked that there is only one copy of the *.ax - the library
with all the functions, also the lines GetCamCaps are functions from
within the ax file - and they are called in both situations.
Thanks for responding - I really need to solve this!
If you think it's a DirectShow question, let me know - I'll transfer
it.
Thanks again,
Mechi
Mechi
>
> - Show quoted text -
BTW - I always check the return codes - hr = RET_OK after returns from
CoCreateInstance in both cases.
Mechi
Mechi
I found the answer - when running from the IDE Visual Studio, the
variables and structures are initialized to 0.
When running from the Explorer (double-click on *.exe) not everything
is initialized - and therefore some values were assumed to be OK,
etc.
Thanks for all the help!
I wish I could publish this answer somewhere else - so it can help
others.
Thanks again,
Mechi
Joseph M. Newcomer
****
Not true. There is nothing at all that stops you from single-stepping release code. See
my essay on "surviving the release version" on my MVP Tips site. Timing, of course, is
always a problem when debugging, but starting with VS2005 or VS2008, even the release
version produces a PDB file (it was *always* an error that this was not done in the past!)
****
>
>The lines of code in question is:
> DebugPrint("b4 CoCreateInstance CLSID_Camelot");
> hr = CoCreateInstance(CLSID_Camelot1, 0, CLSCTX_INPROC_SERVER,
>IID_IBaseFilter, reinterpret_cast<void**>(&pFilter));
> DebugPrint("after CoCreateInstance CLSID_Camelot");
>
>In the IDE, this is the output (note the initialization of the camera
>when CoCreateInstance is called):
> 3828819, -> b4 CoCreateInstance CLSID_Camelot
+7
> 3828826, -> BDR::InitCamera
+6
> 3828832, -> GetCameraCapabilities
+1189
> 3830721, -> after CoCreateInstance CLSID_Camelot
+1
> 3830722, -> GetCamCaps in
+1
> 3830722, -> GetCameraCaps in
+2
> 3830723, -> GetCameraCaps have m_iSensor <-- succeeded in
>accessing camera, sensor
>
>While when double-clicking the *.exe file from the explorer:
> 4050586, -> b4 CoCreateInstance CLSID_Camelot
> 4050589, -> after CoCreateInstance CLSID_Camelot
> 4050589, -> GetCamCaps in
> 4050590, -> GetCameraCaps in
> 4050591, -> GetCameraCaps - no m_pCamera - call Init!! <----
>didnt succeed in accessing camera, pointers are NULL
>
>Note - only 3msec passed from before until after the call. This is a
>definite problem - since the camera is getting accessed, messages are
>sent back and forth on the USB - it definitely takes time.
****
Actually, it might be interesting to set a breakpoint and see if, taking the breakpoint,
that it still fails. There *might* be a timing issue here with respect to your device,
and your observation about the short window may be a factor.
For example, if you toss a Sleep(10) [which will actually sleep 15ms] in, does it change
the picture? I note there is no "BDR::InitCamera" call in the second example, and the
timings are very tight. So why the difference here? What happened to that
BDR::InitCamera call? [This may explain why you get "no m_pCamera"].
I'm presuming that CLSID_Camelot is your own ActiveX control; if not, please clarify.
joe
****
>
>I have no idea how to enter the CoCreateinstance function - what is
>happening inside, why from the IDE are the correct dll/ax functions
>getting called, while from the explorer they are not.
>
>I've checked that there is only one copy of the *.ax - the library
>with all the functions, also the lines GetCamCaps are functions from
>within the ax file - and they are called in both situations.
>
>Thanks for responding - I really need to solve this!
>If you think it's a DirectShow question, let me know - I'll transfer
>it.
>Thanks again,
>Mechi
>
>
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Joseph M. Newcomer
Note that most variables and structures are *not* initialized to 0, but to bogus values
like 0xCCCCCCCC or 0xDFDFDFDF or values like that. You can never depend on initialization
of non-static variables you did not write yourself. In the case of local variables,
values in the release mode are completely random.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Mechi
In answer to your past 2 posts -
The reason why InitCamera wasn't getting called, is that when
CLSID_Camelot (yes, our own ActiveX control), and a new Instance of
CCamera was allocated, the variable/structure that I checked to see if
it was NULL, wasn't - because there was junk (CDCD) in it. Since it
wasn't NULL, I assumed that the initial handshake had already
occurred, and skipped that step.
In short - I had to initialize the structure (memset) when allocated -
and then things worked OK.
Thanks for your timely and right-on-target answers!
Mechi
Joseph M. Newcomer
On Sun, 8 Nov 2009 04:35:30 -0800 (PST), Mechi <mec...@gmail.com> wrote:
>Hi!
>In answer to your past 2 posts -
>The reason why InitCamera wasn't getting called, is that when
>CLSID_Camelot (yes, our own ActiveX control), and a new Instance of
>CCamera was allocated, the variable/structure that I checked to see if
>it was NULL, wasn't - because there was junk (CDCD) in it.
****
Yes, that is expected; if you don't set a variable to NULL yourself, nobody does it
magically for you.
****
>Since it
>wasn't NULL, I assumed that the initial handshake had already
>occurred, and skipped that step.
>In short - I had to initialize the structure (memset) when allocated -
>and then things worked OK.
****
memset is a REALLY Bad Idea. Not just a little-bit-bad, a LOT bad. For example, if I
have the following class
class Something {
public:
virtual void Whatever();
int x;
int y;
int * p;
};
and I do
Something * t = new Something;
memset(t, 0, sizeof(Something));
then I am dead. Why? Because the sizeof the structure includes the vtable pointer, which
is the first element of the structure, and I've just zeroed out the vtable pointer! Calls
on the virtual method crash with an access fault!
It is a VERY bad habit to ever get into, believing that memset makes sense (long ago, in
the prehistory of pure C, it might have made sense; it no longer does). What you want is
a constructor:
class Something {
public:
Something() { x = 0; y = 0; p = NULL; }
...etc.
};
Do not allow yourself to get into the mindset that memset (or, if you want to make more
sense, ::ZeroMemory; leave memset in the dustbin of history) can ever make sense to
initialize a structure. That's what constructors are for. Use them.
joe
****
>Thanks for your timely and right-on-target answers!
>Mechi