I have a windows application that runs constantly and an Outlook Add-in. In
the add-in, I am stripping attachments off of emails and putting them in a
folder on the local machine for the winapp to pick up and process. In the
winapp I am opening excel files programatically, reading the data & closing
the excel file. I am creating a new excel application object using
Excel.Application and kill this object after user. This code is getting
executed very often throughout the day.

After a random amount of time I get an error message of "Not Enough Memory
to run Microsoft Office Excel. Please Close other applications and try again".

I have WinXP Pro, 3Ghz, with 2GB RAM using Office 2003 Enterprise. I have
set the paging size to 3070 with a max of 4096, because that is the max it
would let me set it to. Once I get this error, I am forced to restart the
system if I want to get into any of the Office Applications or allow my
winapp to continue to process, as when this error shows up it disables all
applications not just Excel. I will get the same message if I try to open
Word, Powerpoint or Access as well.

I have updated Office to SP2 and all the latest security patches with great
antcipation that it would solve the problem. Didn't happen!!! Can someone
please help in my crisis?

Are you sure you release all object references before you Quit your Excel,
eg

Set objWSheet = Nothing
objWBook.close true (false)
Set objWS = Nothing
xlApp.Quit
Set xlApp = Nothing

Without knowing your app there maybe other references too, they are not
always obvious. But if they are left clinging you won't be able to fully
terminate your Excel instance, hence rapid memory leak if you are repeatedly
creating new instances.

Regards,
Peter T

"Norra" wrote in message
...
I have a windows application that runs constantly and an Outlook Add-in.
In
the add-in, I am stripping attachments off of emails and putting them in a
folder on the local machine for the winapp to pick up and process. In the
winapp I am opening excel files programatically, reading the data &
closing
the excel file. I am creating a new excel application object using
Excel.Application and kill this object after user. This code is getting
executed very often throughout the day.

After a random amount of time I get an error message of "Not Enough Memory
to run Microsoft Office Excel. Please Close other applications and try
again".

I have WinXP Pro, 3Ghz, with 2GB RAM using Office 2003 Enterprise. I have
set the paging size to 3070 with a max of 4096, because that is the max it
would let me set it to. Once I get this error, I am forced to restart the
system if I want to get into any of the Office Applications or allow my
winapp to continue to process, as when this error shows up it disables all
applications not just Excel. I will get the same message if I try to open
Word, Powerpoint or Access as well.

I have updated Office to SP2 and all the latest security patches with
great
antcipation that it would solve the problem. Didn't happen!!! Can someone
please help in my crisis?

Peter,
Absolutely, I wrote a procedure that I call, called KillExcel and I call
this after every instance of an excel object being opened.

Public Sub KillExcel(ByRef objws As Excel.Worksheet, ByRef objWb As
Excel.Workbook, ByRef appXL As Excel.Application, _
Optional ByVal strSaveAs As String = "", _
Optional ByVal bSave As Boolean = False, _
Optional ByVal bProtect As Boolean = False)
Dim proc As System.Diagnostics.Process
Dim intPID As Integer
Dim intResult As Integer
Dim iHandle As IntPtr
Dim strVer As String

If bProtect Then objws.Protect("password", True, True, True)
If bSave Then
appXL.DisplayAlerts = False
objWb.SaveAs(strSaveAs)
appXL.DisplayAlerts = True
End If
If Not (objws Is Nothing) Then
System.Runtime.InteropServices.Marshal.ReleaseComO bject(objws)
'You must call this if you are using Excel 11.0 Object Library
objws = Nothing
End If
If Not (objWb Is Nothing) Then
System.Runtime.InteropServices.Marshal.ReleaseComO bject(objWb)
objWb = Nothing
End If
If Not (appXL Is Nothing) Then
appXL.Caption = "TRAKKER Excel"
appXL.DisplayAlerts = False
strVer = appXL.Version
iHandle = IntPtr.Zero
appXL.DisplayAlerts = True
appXL.Quit()
If CInt(strVer) 9 Then
PostMessage(appXL.Hwnd, conWM_QUIT, 0, 0)
Else
iHandle = FindWindow(Nothing, appXL.Caption)
intResult = GetWindowThreadProcessId(iHandle, intPID)
proc = System.Diagnostics.Process.GetProcessById(intPID)
proc.Kill()
End If
System.Runtime.InteropServices.Marshal.ReleaseComO bject(appXL)
appXL = Nothing
End If
End Sub


"Peter T" wrote:

Are you sure you release all object references before you Quit your Excel,
eg

Set objWSheet = Nothing
objWBook.close true (false)
Set objWS = Nothing
xlApp.Quit
Set xlApp = Nothing

Without knowing your app there maybe other references too, they are not
always obvious. But if they are left clinging you won't be able to fully
terminate your Excel instance, hence rapid memory leak if you are repeatedly
creating new instances.

Regards,
Peter T

"Norra" wrote in message
...
I have a windows application that runs constantly and an Outlook Add-in.
In
the add-in, I am stripping attachments off of emails and putting them in a
folder on the local machine for the winapp to pick up and process. In the
winapp I am opening excel files programatically, reading the data &
closing
the excel file. I am creating a new excel application object using
Excel.Application and kill this object after user. This code is getting
executed very often throughout the day.

After a random amount of time I get an error message of "Not Enough Memory
to run Microsoft Office Excel. Please Close other applications and try
again".

I have WinXP Pro, 3Ghz, with 2GB RAM using Office 2003 Enterprise. I have
set the paging size to 3070 with a max of 4096, because that is the max it
would let me set it to. Once I get this error, I am forced to restart the
system if I want to get into any of the Office Applications or allow my
winapp to continue to process, as when this error shows up it disables all
applications not just Excel. I will get the same message if I try to open
Word, Powerpoint or Access as well.

I have updated Office to SP2 and all the latest security patches with
great
antcipation that it would solve the problem. Didn't happen!!! Can someone
please help in my crisis?

Your code appears to clear the objects, but if anything overkill !
Why PostMessage WM_QUIT or proc.Kill() when you have already done
appXL.Quit.
Which xl version is giving you problems, if xl2k/xl97 maybe this -

iHandle = FindWindow(Nothing, appXL.Caption)
which follows after you have done appXL.quit !

In passing, I'd change that API call -
appXL.Caption = "tempUniqueCaption" ' strong possibility of multiple apps
ruining
iHandle = FindWindow("XLMAIN", appXL.Caption)
and you could use your postMessage with the older versions with iHandle (to
replace appXL.hWnd) ) iso proc.kill

Are you absolutely sure there are no other objects anywhere in your code?
Might be worth making Excel visible before closing it.

Perhaps Excel is not the problem at all, anything else you can think of.
Does your own app quit properly.

Regards,
Peter T


"Norra" wrote in message
...
Peter,
Absolutely, I wrote a procedure that I call, called KillExcel and I call
this after every instance of an excel object being opened.

Public Sub KillExcel(ByRef objws As Excel.Worksheet, ByRef objWb As
Excel.Workbook, ByRef appXL As Excel.Application, _
Optional ByVal strSaveAs As String = "", _
Optional ByVal bSave As Boolean = False, _
Optional ByVal bProtect As Boolean = False)
Dim proc As System.Diagnostics.Process
Dim intPID As Integer
Dim intResult As Integer
Dim iHandle As IntPtr
Dim strVer As String

If bProtect Then objws.Protect("password", True, True, True)
If bSave Then
appXL.DisplayAlerts = False
objWb.SaveAs(strSaveAs)
appXL.DisplayAlerts = True
End If
If Not (objws Is Nothing) Then
System.Runtime.InteropServices.Marshal.ReleaseComO bject(objws)
'You must call this if you are using Excel 11.0 Object Library
objws = Nothing
End If
If Not (objWb Is Nothing) Then
System.Runtime.InteropServices.Marshal.ReleaseComO bject(objWb)
objWb = Nothing
End If
If Not (appXL Is Nothing) Then
appXL.Caption = "TRAKKER Excel"
appXL.DisplayAlerts = False
strVer = appXL.Version
iHandle = IntPtr.Zero
appXL.DisplayAlerts = True
appXL.Quit()
If CInt(strVer) 9 Then
PostMessage(appXL.Hwnd, conWM_QUIT, 0, 0)
Else
iHandle = FindWindow(Nothing, appXL.Caption)
intResult = GetWindowThreadProcessId(iHandle, intPID)
proc = System.Diagnostics.Process.GetProcessById(intPID)
proc.Kill()
End If
System.Runtime.InteropServices.Marshal.ReleaseComO bject(appXL)
appXL = Nothing
End If
End Sub


"Peter T" wrote:

Are you sure you release all object references before you Quit your
Excel,
eg

Set objWSheet = Nothing
objWBook.close true (false)
Set objWS = Nothing
xlApp.Quit
Set xlApp = Nothing

Without knowing your app there maybe other references too, they are not
always obvious. But if they are left clinging you won't be able to fully
terminate your Excel instance, hence rapid memory leak if you are
repeatedly
creating new instances.

Regards,
Peter T

"Norra" wrote in message
...
I have a windows application that runs constantly and an Outlook
Add-in.
In
the add-in, I am stripping attachments off of emails and putting them
in a
folder on the local machine for the winapp to pick up and process. In
the
winapp I am opening excel files programatically, reading the data &
closing
the excel file. I am creating a new excel application object using
Excel.Application and kill this object after user. This code is
getting
executed very often throughout the day.

After a random amount of time I get an error message of "Not Enough
Memory
to run Microsoft Office Excel. Please Close other applications and try
again".

I have WinXP Pro, 3Ghz, with 2GB RAM using Office 2003 Enterprise. I
have
set the paging size to 3070 with a max of 4096, because that is the
max it
would let me set it to. Once I get this error, I am forced to restart
the
system if I want to get into any of the Office Applications or allow
my
winapp to continue to process, as when this error shows up it disables
all
applications not just Excel. I will get the same message if I try to
open
Word, Powerpoint or Access as well.

I have updated Office to SP2 and all the latest security patches with
great
antcipation that it would solve the problem. Didn't happen!!! Can
someone
please help in my crisis?

My original posts mentioned that I am using Office 2003 so that should tell
you what version. It appears to be overkill but if you researced the history
of appXL.Quit you will find that in VS2003 when referencing the Excel 11.0
Object Library Quit does not actually do that every time som I am forcing it
to Quit in instances where Quit does not actually kill the EXCEL.EXE process
in taskmanager.
The caption I gave it is unique, that is why I gave it a caption to make
sure that is the one that is killed.
As I said in my previous post and reiterate here, I ABSOLUTELY am sure there
are no other objects.
My application quits properly if there are no Excel memory errors, i.e., on
normal occassions. But when I get the memory error I have to force the
process to be killed before I can restart my machine or the machine won't
restart.
Excel may not be the problem but it is an obvious Excel Error that is
causing the problem so therefore I assume it is an Excel problem.

L8r G8r
Tom

"Peter T" wrote:

Your code appears to clear the objects, but if anything overkill !
Why PostMessage WM_QUIT or proc.Kill() when you have already done
appXL.Quit.
Which xl version is giving you problems, if xl2k/xl97 maybe this -

iHandle = FindWindow(Nothing, appXL.Caption)
which follows after you have done appXL.quit !

In passing, I'd change that API call -
appXL.Caption = "tempUniqueCaption" ' strong possibility of multiple apps
ruining
iHandle = FindWindow("XLMAIN", appXL.Caption)
and you could use your postMessage with the older versions with iHandle (to
replace appXL.hWnd) ) iso proc.kill

Are you absolutely sure there are no other objects anywhere in your code?
Might be worth making Excel visible before closing it.

Perhaps Excel is not the problem at all, anything else you can think of.
Does your own app quit properly.

Regards,
Peter T

In message
at 12:00:02 on Fri, 14 Sep 2007, Norra
wrote
My original posts mentioned that I am using Office 2003 so that should tell
you what version.

Have you patched it to SP2 at all?
--
Mike News

Mike,
Did you read all the posts? My original post clearly states "I have updated
Office to SP2 and all the latest security patches with great antcipation that
it would solve the problem. Didn't happen!!!"

Therefore, the answer to your question is found there and just in case you
need it again, YES!!!
"Mike" wrote:

In message
at 12:00:02 on Fri, 14 Sep 2007, Norra
wrote
My original posts mentioned that I am using Office 2003 so that should tell
you what version.

Have you patched it to SP2 at all?
--
Mike News

Comments in line -

"Norra" wrote in message
My original posts mentioned that I am using Office 2003 so that should
tell
you what version.

Indeed you did. Two posts later I had forgotten and instead referred to your
code where you cater for multiple versions.

It appears to be overkill but if you researced the history
of appXL.Quit you will find that in VS2003 when referencing the Excel 11.0
Object Library Quit does not actually do that every time som I am forcing
it
to Quit in instances where Quit does not actually kill the EXCEL.EXE
process
in taskmanager.

You missed my point or perhaps I didn't explain clearly, namely -

You have appXL Quit followed by appXL.Hwnd (or appXL.Caption).
Normally that would throw an error trying to reference the now non existent
app.

If I'm right about a potential error there, speculating, does code pass to
an error handler in the calling routine thereby missing -
System.Runtime.InteropServices.Marshal.ReleaseComO bject(appXL)
appXL = Nothing

Suggest assign the handle (or caption) to an apppropriate variable before
doing appXL.quit.

The caption I gave it is unique, that is why I gave it a caption to make
sure that is the one that is killed.

OK, you hadn't said hence the suggestion.

As I said in my previous post and reiterate here, I ABSOLUTELY am sure
there
are no other objects.

That may well be the case but somethimes object references are not obvious.
FWIW roughly 50% I suggest double checking it proves worthwhile.

My application quits properly if there are no Excel memory errors, i.e.,
on
normal occassions. But when I get the memory error I have to force the
process to be killed before I can restart my machine or the machine won't
restart.
Excel may not be the problem but it is an obvious Excel Error that is
causing the problem so therefore I assume it is an Excel problem.

Did you try my suggestion to make the Excel visible before quitting, say
until the problem is sorted.

L8r G8r
Tom

Regards,
Peter T

"Peter T" wrote:

Your code appears to clear the objects, but if anything overkill !
Why PostMessage WM_QUIT or proc.Kill() when you have already done
appXL.Quit.
Which xl version is giving you problems, if xl2k/xl97 maybe this -

iHandle = FindWindow(Nothing, appXL.Caption)
which follows after you have done appXL.quit !

In passing, I'd change that API call -
appXL.Caption = "tempUniqueCaption" ' strong possibility of multiple
apps
ruining
iHandle = FindWindow("XLMAIN", appXL.Caption)
and you could use your postMessage with the older versions with iHandle
(to
replace appXL.hWnd) ) iso proc.kill

Are you absolutely sure there are no other objects anywhere in your
code?
Might be worth making Excel visible before closing it.

Perhaps Excel is not the problem at all, anything else you can think of.
Does your own app quit properly.

Regards,
Peter T

I cater for multiple versions because it allows me to run my application on
multiple platforms without having to rewrite code. Better safe than sorry
later.

You have a point in regards to the order of precident here and that is
changed now, but that is not what is causing the error.

Double checked, triple checked and quadruple checked but still the same
result.

Did not try your suggestion to make the Excel visible before quitting but I
will try to sneak that in on the next version output.
L8r G8r
Tom