For several months I have been trying to get my MSP7 upgrade from VS8 working under XP Pro SP2. The symptom was that it would crash after some 5 to 20 minutes with no error message (would simply stop responding). There was not any particular action that would cause this.
I had tried *many* solutions found in this and other forums, but what finally solved it in my case was switching the Compatibility Mode setting of the Windows shortcut to "Windows NT 4.0 (Service Pack 5)".
Now that the program will actually run, I am now willing to invest the time to learn it!
In the next 24 hours, I will post a follow up with a list of all the steps I had tried to no avail.
Finally happy,
John from New York
Crashing in MSP7 solved by setting Compatability Mode
-
heinz-oz
MSP7 certainly runs under WIN XP Pro SP2. There is something else causing you grief and I suspect it will come back to bite you when you least expect it.
I think it better to get to the root cause of your problem rather than finding a work around.
Have you checked your memory? How much free space is on the system drive. When did you last defrag this drive. What are your settings for virtual memory (swap file). What is the file system used, NTFS or FAT32? Did you check your discs for errors?
Did you install SP3 for MSP7?
I think it better to get to the root cause of your problem rather than finding a work around.
Have you checked your memory? How much free space is on the system drive. When did you last defrag this drive. What are your settings for virtual memory (swap file). What is the file system used, NTFS or FAT32? Did you check your discs for errors?
Did you install SP3 for MSP7?
-
jbaldwin
Heinz-Oz, you could be right that there is something else. After reading what I tried below, I would be happy to try almost any other steps, except formatting the disk and re-installing the system from scratch!
Also I know that the machine is a little old and slow, but I think I am well above the minimum.
To answer Heinz-Oz’s questions:
1) I checked the RAM (512 MB) with Memtest-86 and found no errors
2) Free space on the drives as follows:
a. C: (system) 44 GB free out of 114 GB
b. D: 35 GB free out of 38 GB
c. G: 218 GB free out of 232 GB
3) Drive was defragged Sunday morning just before my all day session to fix it
4) Virtual Memory is only on the C: drive at an initial 1152 MB to a max 2304 MB
5) File system on all three drives is NTFS
6) All disks were checked for errors using chkdsk /R and were fine.
My steps for trying to resolve this were as follows (I am sure I forgot something here, but this is a good start!):
1) Install MSP*
2) Install MSP7 SP3
3) Used MSCONFIG to remove all Startup Items and non-Microsoft Services
4) Moved project files to a separate drive on a separate controller (project was originally on the C: drive. This step moved it to the G: drive which is a external 1394/Firewire drive)
5) All disks were checked for errors using chkdsk /R and were fine.
6) Bought Diskeeper Pro to thoroughly defrag all drives, including the MFTs and paging file.
7) Used Hardware Profile to disable unneeded hardware devices
8 ) Uninstall and re-install MSP7 and MSP7 SP3. During this step I discovered a permission problem in my Registry. HKLM\Software\Ulead Systems had some sub-keys that had strange permission entries. I had to fix this and then un-install and re-install.
9) Changed priority of the running process veditor.exe to “High” using Task Manager
10) Killed process devldr32.exe from my Soundblaster Card.
11) Changed Compatibility to “Windows 2000”
12) Changed Compatibility to “Windows NT 4.0 (Service Pack 5)”. This seems to have done it.
Thanks,
John
Also I know that the machine is a little old and slow, but I think I am well above the minimum.
To answer Heinz-Oz’s questions:
1) I checked the RAM (512 MB) with Memtest-86 and found no errors
2) Free space on the drives as follows:
a. C: (system) 44 GB free out of 114 GB
b. D: 35 GB free out of 38 GB
c. G: 218 GB free out of 232 GB
3) Drive was defragged Sunday morning just before my all day session to fix it
4) Virtual Memory is only on the C: drive at an initial 1152 MB to a max 2304 MB
5) File system on all three drives is NTFS
6) All disks were checked for errors using chkdsk /R and were fine.
My steps for trying to resolve this were as follows (I am sure I forgot something here, but this is a good start!):
1) Install MSP*
2) Install MSP7 SP3
3) Used MSCONFIG to remove all Startup Items and non-Microsoft Services
4) Moved project files to a separate drive on a separate controller (project was originally on the C: drive. This step moved it to the G: drive which is a external 1394/Firewire drive)
5) All disks were checked for errors using chkdsk /R and were fine.
6) Bought Diskeeper Pro to thoroughly defrag all drives, including the MFTs and paging file.
7) Used Hardware Profile to disable unneeded hardware devices
8 ) Uninstall and re-install MSP7 and MSP7 SP3. During this step I discovered a permission problem in my Registry. HKLM\Software\Ulead Systems had some sub-keys that had strange permission entries. I had to fix this and then un-install and re-install.
9) Changed priority of the running process veditor.exe to “High” using Task Manager
10) Killed process devldr32.exe from my Soundblaster Card.
11) Changed Compatibility to “Windows 2000”
12) Changed Compatibility to “Windows NT 4.0 (Service Pack 5)”. This seems to have done it.
Thanks,
John
-
heinz-oz
Is the project still on the external drive? Strange that it runs under NT 4. Does NT 4 even support IEEE1394? It surely didn't support USB if I'm not mistaken.
It must be something XP specific that stops cummunication via the firewire port, causing the program to hang. Do you have the XP SP2 firewall running? It could prevent certain actions from taking place over the firewire connection. SP 2 treats IEEE1394 connections like any other network connection. What about DEP (data execution prevention), is that disabled?
It must be something XP specific that stops cummunication via the firewire port, causing the program to hang. Do you have the XP SP2 firewall running? It could prevent certain actions from taking place over the firewire connection. SP 2 treats IEEE1394 connections like any other network connection. What about DEP (data execution prevention), is that disabled?
-
jbaldwin
As a follow up to Heinz-Oz’ Ideas, I did the following experiments:
For elimination of Firewire/1394 as a source of the instability, I opened MSP7 without opening a project and removed references to the G: drive from the “Specify additional folders for preview files”. The result was that it would crash after some time if compatibility mode was off and would remain stable if the compatibility mode was set to “Windows NT 4.0 (Service Pack 5)”.
For the Data Execution Prevention experiments: With no project loaded and compatibility mode off, MSP7 exhibited the exact same instability under all three of the following settings (Note that it said my hardware did not support the feature):
a) DEP is only turned on for essential Windows operating system programs and services. (default)
b) Turn on DEP for all programs and services except those I select, with Video Editor on the list and checked on.
c) Turn on DEP for all programs and services except those I select, with Video Editor on the list and unchecked.
My conclusion so far is that the only factor that allows it to run stable is indeed to set the compatibility mode. My next step will be to research what the mode actually does.
Thanks,
John
For elimination of Firewire/1394 as a source of the instability, I opened MSP7 without opening a project and removed references to the G: drive from the “Specify additional folders for preview files”. The result was that it would crash after some time if compatibility mode was off and would remain stable if the compatibility mode was set to “Windows NT 4.0 (Service Pack 5)”.
For the Data Execution Prevention experiments: With no project loaded and compatibility mode off, MSP7 exhibited the exact same instability under all three of the following settings (Note that it said my hardware did not support the feature):
a) DEP is only turned on for essential Windows operating system programs and services. (default)
b) Turn on DEP for all programs and services except those I select, with Video Editor on the list and checked on.
c) Turn on DEP for all programs and services except those I select, with Video Editor on the list and unchecked.
My conclusion so far is that the only factor that allows it to run stable is indeed to set the compatibility mode. My next step will be to research what the mode actually does.
Thanks,
John