|
Is it possible that the error code is right and their class *hasn't* yet been registered?
|
|
|
|
|
No, its runtime dependent. For example I can make FinalConstruct's return value dependent on the existence of a file returning S_OK if present and E_OUTOFMEMORY if not and REGDB_E_CLASSNOTREG is caught when the file is absent.
|
|
|
|
|
Ah, sorry - didn't quite pick up on that 
Anyway - I knocked up a little ATL server project and a client and I get the same behaviour as you (good start). Stepping back through the call stack (and keeping an eye on the value of EAX as that's where function return values are stored), it would seem that the REGDB_E_CLASSNOTREG is introduced inside ole32.dll, i.e. by Windows, because after your InprocServer fails to construct properly, OLE attempts to load your class using other COM server types (e.g. out-of-process server).
To cut a long story short, the correct HRESULT gets passed back to your client so long as you use the correct <a href="http://msdn.microsoft.com/en-us/library/ms693716(VS.85).aspx">CLSCTX</a>[<a href="http://msdn.microsoft.com/en-us/library/ms693716(VS.85).aspx" target="_blank" title="New Window">^</a>] enumeration in your call to CoCreateInstance.
Here's the code I used which picks up the correct HRESULT - my server is an in-process server (i.e. implemented in an ATL DLL project).
::CoInitialize(0);
CComPtr<IUnknown> wibble;
HRESULT hr = wibble.CoCreateInstance(CLSID_paf, 0, CLSCTX_INPROC_SERVER);
To re-iterate, using the appropriate CLSCTX enumeral should allow you to retrieve the correct HRESULT.
|
|
|
|
|
Wow! Excellent work, thanks for your help.
It seems however that you cannot use ISupportErrorInfo, the _com_error::Description is blank. This does however seem to confirm what I read in the microsoft newsgroups, that your not supposed to set any rich error information inside FinalConstruct. This doesn't seemed to be mentioned in MSDN, but then neither is there any info on REGDB_E_CLASSNOTREG for that matter.
Many, many thanks the important thing is they can return an error code from CreateInstance.
Peter
|
|
|
|
|
My application working fine in the dev environment.But in the testing /production environment
it is not working because that environment has only
windows server 2003
IIS
.net2.0 framework
In my application I have Used some microsoft VC++ dll's also along with .net dll's.
Now Iam getting "RUNTime Error" pop-up screen message as below
" The Application has been terminated in an Unusual Way"
On googling i came to know that some dll's like msvcrt.dll of windows server 2003 has to be changed...But Iam not pretty sure about it..
In Production/test environment there is only framework installed ,but there is no visual studio installed on it.may be due that this error may occur...
So kindly post your suggestions and views to help me
I tried the following as suggested by you:
1. I have installled the redistributable package suggested by you.
after installing i restarted the PC even now also I got the same runtime pop-up error.
2. Then I checked even with the dependency walker for the dll.
I found that there is no miising dll.
3. Then I tried by installing Visual C++ express edition..even then also i got the same pop-up error.
Kindly help me.....
|
|
|
|
|
balu12345 wrote: The Application has been terminated in an Unusual Way
IIRC, this generally means an exception's being raised. The error could (shock! horror!) be in your own code - can you put WinDbg [^] on the server and debug it on there? Or even remote debug on the server?
Just noticed that VC++ Express is installed on the machine - you *could* debug with that. If your issue is with a Release build, turn on debug information for the Release build (you can do that without turning off any optimisations) and make sure you copy PDB files with the EXE.
|
|
|
|
|
For example,
class line
{
private:
list<point> m_points;
list<point>::iterator m_selected_point;
}</point></point>
and if no point is selected, I can't write m_selected_point=NULL, how to write it?
redundantless
|
|
|
|
|
As you have control of the lsit and iterator, it should be safe enough. Lists are easier to do this with than vectors or deques, as list iterators are (IIRC) unaffected by insertions or deletions.
Instead of m_selected_point=NULL, use m_selected_point=m_points.end().
|
|
|
|
|
Hello!
I am working on a C# COM-Server and a C++ COM client app. The client in fact loads a dll-plugin containing the COM client in a class that acts as a com event reciever:
extern "C"
__declspec(dllexport)
int ndofInit();
extern "C"
__declspec(dllexport)
void* ndofOpen(void* wnd);
extern "C"
__declspec(dllexport)
void ndofShutdown(void* deviceHandle);
[ event_receiver(com) ]
[ module(type=dll, name="NDOF") ]
class NDOFServer
{
public:
NDOFServer() {}
virtual ~NDOFServer();
...
}
Everytime I start the client I get the following error:
Debug Assertion failed!
Program ...
File: C:\Programme\Microsoft Visual Studio 8\VC\atlmfc\include\atlbase.h
Line 2706
Expression _pAtlModule == 0
Clicking Retry and returning to my code reveals that this error occurs when the constructor of NDOFServer() is called.
The constructor is called this way by the client app:
extern "C"
__declspec(dllexport)
int ndofInit()
{
if (sNdofServer == NULL)
sNdofServer = new NDOFServer();
return 1;
}
This error seems not to occur when the client plugin-DLL is used with another COM server offering the same classes etc. written in C++ (whose code I do not know).
I tried to switch some more or less relevant options in the project properties like:
- MFC usage static/shared/Windows shared
- ATL usage static/shared/none
- minimize CRT usage in ATL yes/no
- CLR support no/CLR
stdafx.h looks like this:
#if defined(_WIN32)
#ifndef WINVER // Allow use of features specific to #define WINVER 0x0501 // Change this to to target other
#endif
#ifndef _WIN32_WINNT // Allow use of features specific to
#define _WIN32_WINNT 0x0501 // (was 0x0501) Change to target other versions
#endif
#ifndef _WIN32_WINDOWS // Allow use of features specific to
#define _WIN32_WINDOWS 0x0410 // Change this to target Windows Me or later.
#endif
#ifndef _WIN32_IE // Allow use of features specific to IE
#define _WIN32_IE 0x0600 // Change this to target other versions of IE.
#endif
#define _ATL_APARTMENT_THREADED
#define _ATL_NO_AUTOMATIC_NAMESPACE
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS
#include <atlbase.h>
#include <atlcom.h>
<---->
//#include <atlwin.h>
//#include <atltypes.h>
//#include <atlctl.h>
//#include <atlhost.h>
--> commenting these headers out did neither help nor hurt
using namespace ATL;
#import "progid:AerionInput.Device" embedded_idl no_namespace
#endif //_WIN32
The C# DLL is nothing spectacular and the "main" class(or the first one being instanciated), which is not instanciated at this time. The COM-visible interface looks like this:
using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
namespace AerionInput
{
[
Guid("CB3BF65E-0816-482A-BB11-64AF1E837812"),
InterfaceType(ComInterfaceType.InterfaceIsDual)
]
public interface ISimpleDevice
{
int Type
{
get;
}
IKeyboard Keyboard
{
get;
}
ISensor Sensor
{
get;
}
void Connect();
void Disconnect();
void LoadPreferences(string preferencesName);
}
}
And the AssemblyInfo.cs reads this like:
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
[assembly: AssemblyTitle("TDxInput")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("n/a")]
[assembly: AssemblyProduct("TDxInput")]
[assembly: AssemblyCopyright("Copyright © n/a 2008")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: ComVisible(true)]
[assembly: Guid("7858b9e0-5793-4be4-9b53-661d922790d2")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
I am doing this on Windows 2000 with Visual Studio 2005 Pro latest SP and .NET 2.0.50727 SP1.
|
|
|
|
|
Christian Bayer wrote: Debug Assertion failed!
Program ...
File: C:\Programme\Microsoft Visual Studio 8\VC\atlmfc\include\atlbase.h
Line 2706
Expression _pAtlModule == 0
It's been a while since I did any ATL dev but that seems like a fundamental ATL error. Meaning you don't have your project configured or initialized properly for ATL use. Do you have any experience using ATL? If not, and you want to use it, I recommend you take the time to study the technology enough to understand the basics. There are plenty of resource on MSDN and I would imagin also here on Code Project that would help, IF you are a beginner.
led mike
|
|
|
|
|
Yes, I am a new to ATL. But I did not program the C++ Client app, it is a GPLed source done by someone who should know the basics well enough. Moreaover as the binary compiled from this source by the author works well, without errors. So I think you are right when you say this is an error due to a wrong inititalization of the project. Next thing is that this project is done with Visual C++ 6.0 or 7.0 and I had to convert it to VC 2005. Perhaps this conversion caused the error? Or could compiling with VC 8.0 can be the reason?
Unfortunately I cannot ask the author himself. Thatswhy I ask here.
You are right, I will have to read some more about ATL. But reading about ATL troubleshooting (what I did) did not solve my problems here.
|
|
|
|
|
Christian Bayer wrote: Moreaover as the binary compiled from this source by the author works well, without errors.
I don't know what "works well" means. If you mean it compiles without error, the problem being reported by the ASSERT only happens at runtime so there is no compile error that will report it.
Christian Bayer wrote: But reading about ATL troubleshooting (what I did) did not solve my problems here.
Yes because troubleshooting information is going to assume prerequisite knowledge of ATL fundamentals.
Christian Bayer wrote: Perhaps this conversion caused the error? Or could compiling with VC 8.0 can be the reason?
Yes it could be a problem, however of course ATL is still supported in all the newer Visual Studio versions. I am not aware of any specific changes to the structure of ATL at that level. AtlModule, if I remember correctly, is an aspect of getting the per Process or per Thread context set up correctly for the ATL libraries to function.
Also the client application must have some sort of configuration requirements to know about COM components it is being directed to use. It is possible you have not satisfied those configuration requirements.
led mike
|
|
|
|
|
led mike wrote: Christian Bayer wrote:
Moreaover as the binary compiled from this source by the author works well, without errors.
I don't know what "works well" means. If you mean it compiles without error, the problem being reported by the ASSERT only happens at runtime so there is no compile error that will report it.
I am not an english native speaker, so I don't know if my sentence was not clear enough: In the source package there was already compiled binary of the client. It was compiled by the author of it a year ago and not me. This binary does not produce the above ATL related error message, nor any other error.
So yes, this error happens only at runtime and is therefore not detected by the compiler (in which case I would not have been able to compile it and report runtime error messages here..)
My project is completely done, everything works as it should (I hope), the only known problem left is the nagging MessageBox popping up everytime the application is started.
led mike wrote: Also the client application must have some sort of configuration requirements to know about COM components it is being directed to use. It is possible you have not satisfied those configuration requirements.
I am not quite sure if there is something wrong with that. But from what I have read on the net about it (I know that you don't believe me if I say it was a lot) the COM init part should be ok. Above all because every COM related function, data structure and event works very well within the client.
If there is something left to connect all these COM structures to something like an "ATL environment", this could cause the error. But remember the above lines, the original binary of the client using the same source but another VC version and perhaps some other non-source code related preferences works without errors.
|
|
|
|
|
Christian Bayer wrote: My project is completely done, everything works as it should (I hope), the only known problem left is the nagging MessageBox popping up everytime the application is started.
Oh that sounds different than what I previously understood. So the application functions property once you dismiss the messagebox? An assert should only be triggered if the project is compiled in _DEBUG. If you can re-compile the binary in release mode it should stop displaying that message.
Again what I just said is ONLY if I now understand your situation correctly.
led mike
|
|
|
|
|
led mike wrote: Oh that sounds different than what I previously understood. So the application functions property once you dismiss the messagebox? An assert should only be triggered if the project is compiled in _DEBUG. If you can re-compile the binary in release mode it should stop displaying that message.
Again what I just said is ONLY if I now understand your situation correctly.
You do. The program runs just fine if you click ignore (which is strange enough for me).
Oh my... I did not think of that... In Release mode the Box is really gone, could have been thinking of that earlier..
But there is still the question why this assertion is triggered. Ok, I can release my app now when I know how this box vanishes but there should be a reason for that, though...
This is also the explanation why the shipped binary "works" - it simply has the same error.
But ok - my project is not the reason for that error and this helps a lot (because this client app is not my problem domain, only the COM-server is) and I do not have to fiddle around with that. Although it would be nice if the GPLed client app can be fixed. If you are still interested, you can download it here:
http://mirror.blenderbuilds.com/plugins/3DxBlender-Windows.zip[^]
|
|
|
|
|
Hi,
I would like to create a windows service which automatically starts on startup and calls my function.I dont want to use .NET support for this.
Using ATL I have taken a windows service project.I build it and registered the service using "/Service" which is then shown in Services with "Manual Startup type". I would want this to be automatic.
How should I go about it? For this while creating the service we need to specify "SERVICE_AUTO_START" flag. But this service creation is automatically done by the base class CAtlServiceModuleT.
SC_HANDLE hService = ::CreateService(
hSCM, m_szServiceName, m_szServiceName,
SERVICE_ALL_ACCESS, SERVICE_WIN32_OWN_PROCESS,
SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL,
szFilePath, NULL, NULL, _T("RPCSS\0"), NULL, NULL);
Now How should I go about overriding the base class functions. I know I need to make use of _tWinMain() and override but Iam not sure of the approach.
Any suggestions or relevant links would be helpful
Thanks
Satya
Today is a gift, that's why it is called the present.
modified on Tuesday, October 7, 2008 4:17 AM
|
|
|
|
|
Override the base implementation via copying the code in your project and change it.
Or you can try to change the startup type of the service yourself (somehow).
Greetings from Germany
|
|
|
|
|
After the Install method of CAtlServiceModuleT is called, you could use OpenService to get a handle on the service and then ChangeServiceConfig to alter the service's start type to SERVICE_AUTO_START?
Looking in the code, you could override RegisterAppId to do that, as RegisterAppId calls the Install method - you can't just override Install, because it's not virtual - RegisterAppId is the closest method called using a correctly typed object pointer (look for pT->RegisterAppId in AtlBase.h). Something like the code below should work?
HRESULT RegisterAppId(bool bService = false) throw()
{
HRESULT hBaseRes = CAtlServiceModuleT< CbModule, IDS_SERVICENAME >::RegisterAppId(bService);
if (SUCCEEDED(hBaseRes) && bService)
{
HRESULT hRes = E_FAIL;
SC_HANDLE hSCM = ::OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS);
if (hSCM != NULL)
{
SC_HANDLE hService = ::OpenService(hSCM, m_szServiceName, SERVICE_CHANGE_CONFIG);
if (hService != NULL)
{
if (::ChangeServiceConfig(hService,
SERVICE_NO_CHANGE, SERVICE_AUTO_START, SERVICE_NO_CHANGE,
NULL, NULL, NULL, NULL, NULL, NULL, NULL))
{
hRes = hBaseRes;
}
::CloseServiceHandle(hService);
}
::CloseServiceHandle(hSCM);
}
hBaseRes = hRes;
}
return hBaseRes;
}
|
|
|
|
|
#define BEGIN_MSG_MAP(theClass) \
public: \
BOOL ProcessWindowMessage(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lResult, DWORD dwMsgMapID = 0) \
{ \
BOOL bHandled = TRUE; \
(hWnd); \
(uMsg); \
(wParam); \
(lParam); \
(lResult); \
(bHandled); \
switch(dwMsgMapID) \
{ \
case 0:
|
|
|
|
|
|
but
(hWnd); \
(uMsg); \
(wParam); \
(lParam); \
(lResult); \
(bHandled); \
are not parameters to the macro.
And, if the parenthsis is removed , nothing wrong happened.
|
|
|
|
|
It was probably just force of habit that made the author put parens around those variables. They're harmless.
|
|
|
|
|
to make the compiler silent about the unused values.
I make that BOOL ProcessWindowMessage(HWND /*hWnd*/,...
Greetings from Germany
|
|
|
|
|
Right, but you don't need parens for that.
|
|
|
|
|
"No doubt about it" 
Greetings from Germany
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
