My problem started with an application that was just deployed. I’m getting an error when the application is closed. This only happens the first time after the initial run of the program where the Connection Wizard is used to configure the connection. After closing the error window I saw that the app was still alive in Task Manager and killed the process.   Re-running the app a second time without running the connection wizard allows the application to exit with no errors.

I went back to the development environment and created a simple app to see if happen there. Attached is screenshot of the error I received there.  

-Larry

How are you getting the exception in the designer?  As we have both experienced, these types of errors are very hard to diagnose since they are generally not created by the environment that is getting the error...just manifested there.

How long have you been getting this?  Can you reproduce on more than one computer? Also, what are the exact steps to reproduce?  Last question, is BatchTrackerWIN.exe something that you have loaded on your machine or is this your assembly EXE?

Sorry for all of the questions, but I have seen exception error a thousand times in my life and it is generally caused by something outside of the environment.

Hi Trent,

I was pretty sure this wouldn’t be easy.

In the Designer:

·     Delete connection data under All Users\Application Data

·     Open VS

·     StrataFrame prompts for StrataFrame Data base connection info, enter info

·     Open test project, a SF Windows with Security App containing one form and 2 BOs

·     Click run in debug

·     SF displays connection Wizard to configure data source for test app, enter data

·     Authentication Form is displayed, Click Exit

The message “The exception unknown software exception (0xc002001) occurred in the application at location 0x7c812a5b.  Click on OK to terminate the program.  (See attachment SFTest1b)

Even after you click OK, the app continues to run and you either have to click on Stop Debugging or kill the process in Task manager.

The test project has been configured to disable the Visual Studio Hosting process. This results in the same error that I received on the deployed version of my full app. If Visual Studio Hosting Services are enabled, the error is slightly different (See attachment SFTest1c)

Now that the database connection has been established I can start the application and exit at the same point (or anywhere else) with no exceptions.

In Deployment:

If I take the same test app and deploy it to another PC and run the Connection Wizard and exit at the Authorization form I get an exception and the app appears to exit but continues to run in Task Manager.

(See SFTest 1d)

BatchTracker is the application we’ve put together. It tracks client records through a document imaging process.  However the tests that I’ve just done were with a very simple test app with one form and couple of BOs.

I’ve seen this exception a few times in VS but it was so infrequent that I didn’t really notice it. So far I tried deploying our tracking app to five different PCs and the results are all the same.

My system is the only one running V1.51 (10/30/06) and no one else has noticed the issue on v1.4. I’m out of the office tomorrow but when I get back I’ll try loading up another development system with 1.51 and see if I can reproduce the error since there is the possibility that there may be a damaged dll on my system. I’ll let you know what I find out.

I just figured I’ve give you guys a shout in case you’d run into the same issue before I build another PC. Layering on all this software on a development machine is a real pain.  

-Larry

I know that you do not want to hear this, but I have tested this on two different computers, and spent a fair amount of time on this including last night at home, and I cannot reproduce this.  There is something in your application, development, and/or run-time environment that is not playing nice with your assembly.

You know us, we like to fix things , but we have to be able to reproduce them before we can.  Obviously this is an isolated type of thing in your environment otherwise we would be hearing about this from every one of our users....not that it makes you feel any better  

Have you loaded any type of patch to VS 2005, the OS, or something that could be playing a part here?

Trent,

I’ve done quite a bit of testing and in all cases I’ve been able to consistently reproduce the application exception I’ve been getting. It is important to note that the exception ONLY occurs on a SF Windows Application with Security. A standard SF Windows Application does not exhibit the problem.

The exception only happens on exiting the application if the Database Connection Wizard has been run in the current instance, either on startup where the applications data base has not yet been defined or if run from the File menu on a SF Main form. If run from the File menu you must run the wizard all the way through the Finish step for the exception to occur on exiting the application.

So far I haven’t been able to isolate the cause of this problem. It’s happening on every PC where I try to deploy an app as well as two development PCs that I’ve tested. To eliminate as many variables as possible, I’ve also done the following, once under Windows XP Pro SP2 and once using Windows 2000 Pro SP4. In both cases I received an exception (although at different locations depending on the OS). I could be missing something when I’m setting up the environment and building the test app, but I can’t see what it is. Maybe you can.

·     Started with a Dell GX280 and reformatted the drive.

·     Installed Windows XP Professional SP2 with no additional updates

·     No anti-virus software installed on PC

·     Installed VS2005 Professional, default install from Dec 2005 Microsoft volume licensing discs. No additional updates or patches installed.

·     Installed SQL Server 2005 STD using Dec 2005 Microsoft volume licensing, all services installed. No additional patches or updates installed.

·     Rebooted PC

·     Installed SF v1.5 11/09/06 without DevExpress or Infragistics with StrataFrame DB on local SQL instance

·     Created a Security project and added 1 user (used “MySecurityKey” for key)

·     Ran DDT to create a database that includes 1 table + Security tables, no localization or message tables

·     Deployed the new DB to the local SQL instance with the data from the Security project

·     Created a new StrataFrame Windows project with security. No modifications to AppMain

·     Replaced the standard form with a SF main form.  Left name as Form1 with no code added

·     No business objects were added to the project

·     Ran program in designer

·     In the connection wizard configured the app to use the new data base with Windows security.

·     When the Authorization form is displayed, clicked on Exit

·     Program throws an application exception (same as previous posts)

·     Clicked on Stop Debugging.

·     Re-Ran application

·     When the Authorization form is displayed, clicked on Exit

·     Application exited with no exception

·     Re-Ran application

·     Entered ID and password on Authorization form,  clicked OK

·     Main form is displayed

·     Clicked on File, Database Connection menu

·     Selected the current connection

·     Clicked on Edit

·     Ran through the Connection Wizard, leaving the information the same

·     Clicked Cancel on the connection windows to close

·     Closed the Main form to exit application

·     Application exception raised

All the PCs where I’ve tested running the VS2005 design environment are Dell GX280 or GX620 systems. Deployed systems have been GX620s as well as no-name clones running either Windows XP SP2 or Windows 2000 Pro SP4.

After running the initial test of the bare bones XP machine, I applied all of the latest XP patches and SQL 2005 SP1.  The results were still the same.  As far as I’m aware there are no SPs for VS2005. I’ve tried using local databases and remote databases. I’ve even taken the development systems off the network. The results are always the same.

Any suggestions would be appreciated since the current situation is making deployment of SF applications very difficult (I’m using a shared configuration file). I haven’t tried it yet but I’m assuming that I could work around the issue by hard coding the connection string in AppMain.

-Larry

Also, I am assuming that if you manually set the DataSources collection and circumvent the Connection Wizard, you do not get the error...correct?  Try taking the shared settings file out of the formula first, then we will go to hard-coding the path.  Let's get the error to go away and then we can start adding things back in.  Thanks.

In my application I’m using SF Security only for password validation. The only restriction we have for our tracking app is that the user is an authenticated user. I haven’t defined any roles or permissions. My Test application contains just one user with no roles or permissions. This doesn’t cause any problems with the app; everything works fine except when the Connection Wizard is run. I did try creating a role and permission for the one user but that didn’t seem to change anything. I’m wondering if I’m missing something when setting up a project with security. It’s driving me nuts that you can’t reproduce this problem when I can 100% of the time on four different development machines running two different operating systems.

-Larry

Trent,

I do all my development in VB but I thought I run a test in C# and see if the results were any different. My test application is nothing more than a SF Windows app with security and one form, a SF Main form. I’ve added no code to what is generated from the templates. I ran the app, manually entered the connection data in Connection Wizard and clicked on exit when the authorization form was displayed. Attached in a screen shot of the error I received.

-Larry

Here is a little more info. I enabled unmanaged code debugging on my VB test app and the following showed up. It corresponds to the exception I'm getting.

Just in case I didn’t make it clear in my previous posts, when the Connection Wizard is run within an application, you have to either add a new connection or edit the existing one for the exception to occur. Simply selecting another connection from the list of available connections will not produce an exception.

-Larry

-Larry 

The issue with the unknown software exception is continuing to cause problems. It’s now showing up in other parts of my application. I have an Active Reports viewer control in the application. When I go to print the report, a standard printer dialog is displayed. If I simply click print, the report is printed and when I exit the program, it terminates normally. However if I open the dialog, make some changes to the printer settings, and then cancel the printer dialog, when I close the program I get an application exception at the same location as when working with the connection wizard. Performing the same steps with Active Reports outside of a StrataFrame application does not produce the error.

I’ve attached an example of a project that displays the exception. It’s nothing more than a SF windows application with role based security that contains a SF main form. I’d like to know if you get the same error when performing the following steps. Again this error only happens in SF application with role based security. An application without role based security does not have this problem.

Run app in debug

Database Connection Wizard is displayed

Click Next

Select any database (there are no business objects)

Click Next

Click Finish

On login screen, click Exit

Program aborts with an unknown exception.

comment out the line within the InitApplication() method that calls the StartSessionMonitoring() on the SessionLock class and see if you still get the error.

-Larry

SessionLock.StopSessionMonitoring();

The SessionLock class uses some low-level OS hooks to trap the mouse and keyboard input to determine when the session is idle... looks like your MDAs are catching the error and displaying it.

I'd like to suggest that you add that one line of code to the standard AppMain just in case some other unfortunate individual runs into this

-Larry

Not that I like to wish problems on other people, but it’s nice to know there is at least one other person who experienced this problem.  It was extremely frustrating as I could reproduce it 100% of the time on every PC that I tired in our organization and it never seemed to show up anywhere else.  I suspect that other people may have had the problem but wrote it off as a VS2005 glitch since it only happened under certain conditions.

Ultimately the SF guys came through with a solution, as they always do, and we can move on to the next challenge