As Cynthia recommended, this isn't an issue that can be resolved here. It is often caused by memory mismanagement under Windows and there are many, many ways in which you can break a Window.
In some cases, this can cause instability in your SAS session and close the SAS session on you. In some more severe cases it can mean the OS session becomes so unstable that Windows shuts down, or asks you to terminate applications and restart. When either happens, you lose your code changes and the log record of what was happening when the error arose. To limit the impact of these issues, I have 2 strategies.
KEEP THE LOG. When I start a SAS session, I do so with a command line that includes the following statements: " -altlog c:\saswork\session.log -unbuflog". The second statement causes SAS to send its log messages as they arise, rather than wait until there is a "page" of data to write. The first specifies the place to send all the log messages. You will still have your usual log window, but now there is a file copy preserved after your session is closed. Debugging becomes much simpler.
HE SAVES. I regularly save my code as I develop it and before I submit it, then when a silly Windows error kills my SAS session I still have my code saved to that point.
With a full log, and a true copy of the code causing the error, you have a better chance of having some evidence for Tech Support to identify the problem.
Sorry if I am off topic Cynthia, but I think this is a fairly important generic issue.
Kind regards
David
