Re: Quality Monitor question

am9518 · ‎May 13, 2003

I just started working with Quality Monitor in Admin Studio 5.0 SP1 and had some questions.

In the Class ID view, under the failed items, is there an explaination why these items didn't register? Does Quality Monitor suggest dependant dll's or ocx's that are missing and are needed to register my failed file correctly?

Also, I don't think that Quality Monitor is reporting Failed Class ID's correctly. I walked through a couple of of failed Class ID's and it looked like the dll actually registered correctly.

Any help would be appreciated.

Thanks!

RajeshTammana · ‎May 13, 2003

We store the reason for failure for each failed item. For seeing this, pls doulbe click the item and see the Details section in the pop up dialog. You can also get to this dialog by selecting the Details... Right click menu.

Right now QualityMonitor does not display the dependant Dlls. We will consider adding this in future.

For verifying the validity of the classid, we call CoCreateInstance and query for IUnknow interface which is the basic interface any COM component should support.

A call to CoCreateInstance could fail, even if the DLL is registered properly.

Regards
Rajesh Tammana

am9518 · ‎May 13, 2003

So if Quality Monitor is providing lots of false positives, what good is the tool? I clicked on the failure and it didn't give me any useful info. I just said the the Class wasn't registered.

I was really hoping this tool would proivde usefull info, like a better Dependency Walker.

I wonder if I am missing anything, but as far as I can tell Qaulity Monitor may be telling me something important but I won't be able to tell because of all the false positives/negatives.

RajeshTammana · ‎May 13, 2003

We will try adding dependancy walker in future.

You may want to try Runtime tests feature which monitors the actual execution of the applications and and reports the runtime errors. So in your case, by actually running the application you would know whether the COM component is registered properly or not.

Regards
Rajesh

am9518 · ‎May 13, 2003

I've tried that, and the application fails. But Quality Monitor says that the application runs correctly. (i've tried this on 4 or 5 *.exe's with the same poor results).

Couldn't I just run the package on my own and see the package fail becaue of the dll not being registered?

I'm not trying to be a jerk, but can you suggest any other parts of Quality Monitor that are extremely valuable?

RajeshTammana · ‎May 19, 2003

Hello,

Is there any way we could get the package you are working with and try to reproduce the issues here.

By having the application here, we can dig more into the COM class reporting issues and runtime tests.

Pls. contact me at rajesht@installshield.com

Regards
Rajesh Tammana

am9518 · ‎May 20, 2003

I'll put something together for you next week.

Thanks!

CChong · ‎May 21, 2003

In regards to the testing of CLSIDs, we basically call CLSIDFromString and then call CoCreateInstance on IUnknown. If either of these fail, then we mark the test as failed. It is possible for registry entries to exist but creation of the object may still fail. This can also be seen using other tools such as the OLE/COM Object Viewer that comes with MS Visual Studio. The CLSID info will show up in there, but if you try to create an instance of it, you will se the same result.

Joe

am9518 · ‎May 22, 2003

Quality Monitor shows the same results if I manually register the *.dll or *.ocx. When I manually register the file (regsvr32.exe) the file responds with a success message. Is this not a complete success? I used Dependency Walker to see if I was missing any dependencies. I wasn't. Can you suggest a few types of remediation to get the file correctly registered on the workstation? The COM info that I am using in the Merge Module was extracted using the Component Wizard. Is the Component Wizard not working correctly?

Thanks!

CChong · ‎May 22, 2003

When you self register a dll, basically, all it does is create registry entries. When self registration succeeds, all we know for sure is that the dll was loaded successfully (meaning any static dependecies exist), the DllRegisterServer method was found and it succeeded. That does not guarantee that you can create instances on the interfaces that dll exposes.

We could have designed QualityMonitor to just check that the registry entries exist but we wanted to take it a step further and see if these CLSIDs and ProgIds would actually execute. Since all COM objects inherit from IUnknown, in theory, we should be able to create an instance of that object through IUnknown. However, it may turn out that in reality, this check is a bit too stringent.

It is possible that these objects fail because of dynamic dependencies, or some configuration is wrong, or some other objects need to be created first. It is also possible that the application may still work because it may not use those objects, or it knows how to use them. Or it may be a problem with the installation. It will vary from case to case.

We welcome input on this feature and we will see what we can do to improve the overall experience.

Joe

am9518 · ‎May 22, 2003

Thanks for the information. It sounds like MS has really made it difficult to truly detect a complete file registration.

Here are some suggestions:

1.) Can you add the dynamic and static scan that are in Developer to Quality Monitor and report the missing dependencies?

2.) If a particular ClassID or ProgID 'fails' can you give a verbose report why it failed? Maybe indicate what registry entries were successfull and which ones were not. Or add any other info that might be important.

3.) Can you add a complete file scan to Quality Monitor that verifies which files actually got installed by the package? If certain files didn't get installed, check to see if their component/ feature had a condition and then list that condition as to why those files didn't get installed. Reporting the file attributes would be great too (read only & hidden are sometimes a problem).

Thanks!

CChong · ‎May 22, 2003

Those all sound like good ideas.

1) We have scanning support in the repackager IDE, so we could add it to QualityMonitor as well.

2) We try to report as much information as we can. When you double click on an item that failed, it should provide an error number and description. We'll investigate and see if there is more we can do along these lines.

3) This is something we already were considering for a future release.

Thanks for the feedback, and we'll see what we can do.

Joe