Hello All,
I am implementing a notify object for my NDIS intermediate driver. I already went through the notify sample provided with the Windows driver kits 8.1 to start.
To create the notify object I am using Visual Studio 2013 community edition. I use the ATL com model to create the COM server as described here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff546254(v=vs.85).aspx
I have already managed to build the DLL with INETCFG interface routines implemented. But when i use the DLL with my driver I get an error
“Could not add the requested feature. the error is: the specified module could not be found”
The notify sample still uses the obsolete CComModule for the com server implementation which makes it difficult for me to relate the issue with the sample code. Can someone explain me the major changes which should be kept in mind during the migration to ATL 7.0? Also is there any reading or sample available which uses the new ATL version for the implementation? I am new to ATL, so if someone can also point me to ways to debug the issues with COM it will a great help too.
Thanks in advance.
Regards
Gaurav
Hi,
Check the wheather Com has created an instance of coCreateInstance, if it
is success then their is no problem in interfce routine, else interface
routine is not a valid one.
other thing is that builded DLL files is in c:\windows\system32 check it
is loaded.
Regards
kumararao
On Tue, May 26, 2015 at 12:16 PM, wrote:
> Hello All,
>
> I am implementing a notify object for my NDIS intermediate driver. I
> already went through the notify sample provided with the Windows driver
> kits 8.1 to start.
>
> To create the notify object I am using Visual Studio 2013 community
> edition. I use the ATL com model to create the COM server as described
> here:
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff546254(v=vs.85).aspx
>
> I have already managed to build the DLL with INETCFG interface routines
> implemented. But when i use the DLL with my driver I get an error
>
> “Could not add the requested feature. the error is: the specified module
> could not be found”
>
> The notify sample still uses the obsolete CComModule for the com server
> implementation which makes it difficult for me to relate the issue with the
> sample code. Can someone explain me the major changes which should be kept
> in mind during the migration to ATL 7.0? Also is there any reading or
> sample available which uses the new ATL version for the implementation? I
> am new to ATL, so if someone can also point me to ways to debug the issues
> with COM it will a great help too.
>
> Thanks in advance.
> Regards
> Gaurav
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>makes it difficult for me to relate the issue with the sample code. Can someone explain me the major
changes which should be kept in mind during the migration to ATL 7.0?
Add debug traces to all important paths of your code, and look whether it is called at all.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
We definitely support using the latest versions of ATL to implement notify objects. I’ve written a few myself using CAtlDllModuleT, and it works fine. Indeed I recommend using CAtlDllModuleT instead of the old CComModule, since it typically results in cleaner code.
“The specified module could not be found” suggests a DLL couldn’t be loaded, possibly one of your dependencies. This isn’t anything to do with COM or netcfg. Check that your DLL can be loaded, e.g., with regsvr32.exe or depends.exe. (One common culprit: building in debug mode with VS causes a dependency on the CRT DLL, which isn’t installed by default. Make sure you have the retail/debug CRT available.)
You can create a little test EXE that calls CoInitializeEx, CoCreateInstance(your clsid, IID_INetCfgComponentControl). Then you’ve got networking out of the picture, and you can just make sure the COM bits work.
You don’t need much to get a simple notify object going with ATL. Below the skeleton of the code for a minimal notify object.
// dllmain.cpp
class MyNotifyObject : public CAtlDllModuleT { };
static MyNotifyObject g_MyNotifyObject;
EXTERN_C
BOOL WINAPI DllMain(
In HINSTANCE hInstance,
In ULONG ulReason,
In PVOID lpReserved)
{
return g_MyNotifyObject.DllMain(ulReason, lpReserved);
}
Use_decl_annotations
EXTERN_C
STDAPI DllGetClassObject(
REFCLSID rclsid,
REFIID riid,
LPVOID *ppv)
{
return g_MyNotifyObject.DllGetClassObject(rclsid, riid, ppv);
}
EXTERN_C
STDAPI DllCanUnloadNow(void)
{
return g_MyNotifyObject.DllCanUnloadNow();
}
EXTERN_C
STDAPI DllRegisterServer(void)
{
return g_MyNotifyObject.DllRegisterServer(FALSE);
}
EXTERN_C
STDAPI DllUnregisterServer(void)
{
return g_MyNotifyObject.DllUnregisterServer(FALSE);
}
// mynotifyclass.h
class MyNotifyClass :
public CComObjectRoot,
public CComCoClass,
public INetCfgComponentControl
{
public:
DECLARE_NO_REGISTRY();
private:
DECLARE_NOT_AGGREGATABLE(MyNotifyClass);
BEGIN_COM_MAP(MyNotifyClass)
COM_INTERFACE_ENTRY(INetCfgComponentControl)
END_COM_MAP()
//
// INetCfgComponentControl
//
HRESULT STDMETHODCALLTYPE Initialize(
In INetCfgComponent *pIComp,
In INetCfg *pINetCfg,
In BOOL fInstalling);
HRESULT STDMETHODCALLTYPE ApplyRegistryChanges();
HRESULT STDMETHODCALLTYPE ApplyPnpChanges(
In INetCfgPnpReconfigCallback *pICallback);
HRESULT STDMETHODCALLTYPE CancelChanges();
};
OBJECT_ENTRY_AUTO(CLSID_MyNotifyClass, MyNotifyClass);
Jeffrey Tippet wrote:
We definitely support using the latest versions of ATL to implement notify objects.
I have to chuckle at the use of the word “latest” to refer to ATL 7.0,
which came out with Visual Studio 2002.
“The specified module could not be found” suggests a DLL couldn’t be loaded, possibly one of your dependencies. This isn’t anything to do with COM or netcfg. Check that your DLL can be loaded, e.g., with regsvr32.exe or depends.exe. (One common culprit: building in debug mode with VS causes a dependency on the CRT DLL, which isn’t installed by default. Make sure you have the retail/debug CRT available.)
Another common failure with an in-process server is a mismatch on the
processor type. You can’t call 64-bit COM server from a 32-bit
process. If you intend to support both sizes, you need to place and
register two DLLs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.