COM+ Server and Client's kernel32.dll 0xc000008f error
Today I had a terrible morning.
The first item on today’s to-do list was to publish a new version of a system at work.
This system in particular, is developed in VB6, accessing the business objects through a COM+ server. It’s comprised of an executable file, and 63 separated DLLs. One for each object (don’t ask me why).
Anyway, last week I proposed to the management to consolidate this 63 DLLs in two easier manageable DLLs, which was accepted and I fixed this in less than an hour. Just to consolidate the code, I've built two different DLLs, one for the data objects, another for the business objects.
So, today was the day to publish the new version.
To maintain a fallback approach I decided to create a separate COM+ application on the server to install these two new DLLs. The policy here at the company is that the developers don’t touch the servers, let alone create applications on the server. So this task was done by the company infrastructure guys, with a little bit of my supervision.
Because I wanted to create a new COM+ application, I decided to copy the properties of the original application, so it would make the transition easier.
Every single property matched… except for the user.
The original application used a local user on the server that, given the server’s age, the infrastructure guys didn’t have the password for it. So, they created a new user for this, and set this new user as the user for the new COM+ application.
The DLLs were installed and the system deployed.
Everything seemed to work fine… until, out of the blue, the system displayed a GPF, and every single user rang on my phone complaining that the system was faulty.
Darn, on the developer’s box the system ran fine. So I created a virtual machine from scratch to test the application. And lo and behold, the system crashed.
The reported GPF error was at the kernel32.dll with an error code of 0xc000008f. Google was no help to decipher this error.
The only different point was the COM+ server between the client’s boxes and the developer’s box.
So, something was wrong with the COM+, but all the settings seemed OK, exactly the same as the original application.
I installed a developer’s set on the virtual machine in an attempt to debug the problem.
Running in debug mode the GPF was averted, but the VB reported an Access Denied error.
And that shed some light into the problem.
Because the users were different, the infrastructure guy that created the new user didn’t copy all the properties from the original user.
So the code attempted to access some code that was protected, or somehow unavailable, at a lower user access.
The basic problem is that the object didn’t report the Access Denied error in the first place; instead the application generated a GPF.
OK, now you have it.
If you ever use a COM+ and have an application throwing a GPF you can also check the user’s permission at the COM+ server.
The first item on today’s to-do list was to publish a new version of a system at work.
This system in particular, is developed in VB6, accessing the business objects through a COM+ server. It’s comprised of an executable file, and 63 separated DLLs. One for each object (don’t ask me why).
Anyway, last week I proposed to the management to consolidate this 63 DLLs in two easier manageable DLLs, which was accepted and I fixed this in less than an hour. Just to consolidate the code, I've built two different DLLs, one for the data objects, another for the business objects.
So, today was the day to publish the new version.
To maintain a fallback approach I decided to create a separate COM+ application on the server to install these two new DLLs. The policy here at the company is that the developers don’t touch the servers, let alone create applications on the server. So this task was done by the company infrastructure guys, with a little bit of my supervision.
Because I wanted to create a new COM+ application, I decided to copy the properties of the original application, so it would make the transition easier.
Every single property matched… except for the user.
The original application used a local user on the server that, given the server’s age, the infrastructure guys didn’t have the password for it. So, they created a new user for this, and set this new user as the user for the new COM+ application.
The DLLs were installed and the system deployed.
Everything seemed to work fine… until, out of the blue, the system displayed a GPF, and every single user rang on my phone complaining that the system was faulty.
Darn, on the developer’s box the system ran fine. So I created a virtual machine from scratch to test the application. And lo and behold, the system crashed.
The reported GPF error was at the kernel32.dll with an error code of 0xc000008f. Google was no help to decipher this error.
The only different point was the COM+ server between the client’s boxes and the developer’s box.
So, something was wrong with the COM+, but all the settings seemed OK, exactly the same as the original application.
I installed a developer’s set on the virtual machine in an attempt to debug the problem.
Running in debug mode the GPF was averted, but the VB reported an Access Denied error.
And that shed some light into the problem.
Because the users were different, the infrastructure guy that created the new user didn’t copy all the properties from the original user.
So the code attempted to access some code that was protected, or somehow unavailable, at a lower user access.
The basic problem is that the object didn’t report the Access Denied error in the first place; instead the application generated a GPF.
OK, now you have it.
If you ever use a COM+ and have an application throwing a GPF you can also check the user’s permission at the COM+ server.
posted by Paulo Santos
|
2/26/2008 07:59:00 PM
|
0 comments
