This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Having this problem as well
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2010
12:21 PM
Build fails: Runtime Error!, ....isdev.exe, abnormal program termination
I have an Installscript project that will build once, then fail each time afterwards until I reboot my computer. It pops a msgbox with the runtime error indicated in the title. I click OK to close the msgbox and then get another error msg: isdev.exe - Application Error The exception unknown software exception (0xc0000409) occurred in the application at location 0x78bfb3e3.
I'm using Windows XP sp3 and InstallShield 2010 sp1.
Searching this forum, I've found a few posts where others have had this (or a similar) issue, but I haven't found a solution.
Is there a fix/workaround for this?
I'm using Windows XP sp3 and InstallShield 2010 sp1.
Searching this forum, I've found a few posts where others have had this (or a similar) issue, but I haven't found a solution.
Is there a fix/workaround for this?
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
02:06 PM
Wow. 4 days and not a single view??? :confused:
I know others have had this problem. Could someone please point me to a solution?
Please?
I know others have had this problem. Could someone please point me to a solution?
Please?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 06, 2010
05:47 PM
dmhines wrote:
Wow. 4 days and not a single view??? :confused:
Please?
I notice that if you build to a different Release Name it works, seems like something to do with the release's pane.
You would think they would have fixed this by now. I think tons of people hit this.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 07, 2010
06:16 PM
Allow me to show you how simple it is to re-create this error.
I am on XP Professional Service Pack 3 on a very new Lenovo T500 laptop Initel Core 2 Duo CPU P8800 @ 2.6 GHz with 3 Gig of Ram.
1. Create New Project
Open InstallShield 2010
File -> New -> InstallScript project.
2. Add a File and Save Project
Installation Designer tab -> (leftmost pane) Organization -> Setup Design
(middle pane) Setup Design -> DefaultFeature -> DefaultComponent -> Static File Links -> (rightmost pane) Right-Mouse Click -> Add...
Add any text file.
File -> Save.
3. Build Project
(leftmost pane) Media -> Releases
(middle pane) Releases -> Right-Mouse Click on Releases -> New Release -> Network Image.
(middle pane) Releases -> Right-Mouse Click on Release 1 -> Build.
Wait for the build to finish.
It succeeds.
4. Build Over Again
(middle pane) Releases -> Right-Mouse Click on Release 1 -> Build.
Wait for the build to start working.
Then a "Miscrosoft Visual C++ Runtime Library" error dialog will appear with the following text:
Runtime Error!
Program: C:\Program Files\InstallShield\2010\System\isdev.exe
abnormal program termination
Click on the only button on this dialog (OK).
After that the InstallShield IDE is forced to close by the OS (crash).
I would not consider this a graceful exit.
Does anybody know the workaround?
Does anybody know why such a severe crash bug still exists?
I am on XP Professional Service Pack 3 on a very new Lenovo T500 laptop Initel Core 2 Duo CPU P8800 @ 2.6 GHz with 3 Gig of Ram.
1. Create New Project
Open InstallShield 2010
File -> New -> InstallScript project.
2. Add a File and Save Project
Installation Designer tab -> (leftmost pane) Organization -> Setup Design
(middle pane) Setup Design -> DefaultFeature -> DefaultComponent -> Static File Links -> (rightmost pane) Right-Mouse Click -> Add...
Add any text file.
File -> Save.
3. Build Project
(leftmost pane) Media -> Releases
(middle pane) Releases -> Right-Mouse Click on Releases -> New Release -> Network Image.
(middle pane) Releases -> Right-Mouse Click on Release 1 -> Build.
Wait for the build to finish.
It succeeds.
4. Build Over Again
(middle pane) Releases -> Right-Mouse Click on Release 1 -> Build.
Wait for the build to start working.
Then a "Miscrosoft Visual C++ Runtime Library" error dialog will appear with the following text:
Runtime Error!
Program: C:\Program Files\InstallShield\2010\System\isdev.exe
abnormal program termination
Click on the only button on this dialog (OK).
After that the InstallShield IDE is forced to close by the OS (crash).
I would not consider this a graceful exit.
Does anybody know the workaround?
Does anybody know why such a severe crash bug still exists?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2010
10:16 AM
I followed your steps on a recently created Windows XP SP3 virtual machine with all express updates from Windows Update installed. I was able to build three times in a row without a crash, each by right clicking Release 1 and selecting Build. Are you using any unusual antivirus software or drivers?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2010
10:45 AM
I've seen this before too....this is how I figured out that my virus scanner was on-access scanning the files and not releasing the handles to the folder where the build output goes. I added the entire install project's source directory (and below) to the virus scan exception list and it stopped crashing. YMMV
1. Down load Sysinternals Process Monitor. (www.sysinternals.com)
2. Run ProcMon with filters set to examine processes named isdev.exe
3. The last file or folder either under the installshield installation directory or your project directory that gets touched before the crash is most likely being held open by virus scan, back up software, or some other tool.
4. Open up the filter set to all processes again, re-run, stop the trace when the isdev crashes, stop ProcMon then examine the trace log around the file that gets hung up. (yes, it's going to be a LOT of data to pour over...)
If there's another process that is scanning it and holding open a file/folder handle, try disabling the offending perogram and see if it is reproducible. If it is a dll that gets loaded into the windows.exe/windows shell (like a BHO or shell addin), see if uninstalling the add-in using HiJackThis or uninstalling the program helps.
If you can solidly reproduce it, you can exclude the directory/file from the scan/backup/whatever.
1. Down load Sysinternals Process Monitor. (www.sysinternals.com)
2. Run ProcMon with filters set to examine processes named isdev.exe
3. The last file or folder either under the installshield installation directory or your project directory that gets touched before the crash is most likely being held open by virus scan, back up software, or some other tool.
4. Open up the filter set to all processes again, re-run, stop the trace when the isdev crashes, stop ProcMon then examine the trace log around the file that gets hung up. (yes, it's going to be a LOT of data to pour over...)
If there's another process that is scanning it and holding open a file/folder handle, try disabling the offending perogram and see if it is reproducible. If it is a dll that gets loaded into the windows.exe/windows shell (like a BHO or shell addin), see if uninstalling the add-in using HiJackThis or uninstalling the program helps.
If you can solidly reproduce it, you can exclude the directory/file from the scan/backup/whatever.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2010
10:21 PM
Thank you , xprt4y , and MichaelU for responding.
Indeed it was the McAfee virus scanner. Once I disabled the on-access and other running McAfee services I was able to build over and over again without seeing the crash. Then turning the virus scanner back on only allowed me to build once and then the second attempt crashed the InstallShield IDE.
Also, with the virus scanner turned off, my project built a lot faster too.
I don't think the InstallShield IDE should crash so horribly if a folder is locked or some 3rd party process is doing something considered normal.
It should probably just halt the build and complain with an error; I have seen it do it this more graceful way when a Windows Explorer navigation window is open looking at the media's release folder and a more graceful halt of the build would be better.
A defect might be a good idea for the InstallShield dev team but I'll leave that up to others to decide.
Still, thank you very much MichaelU for the fix and resolution of this thread!! 🙂
And also, thank you xprt4y for the great investigation details!! That's some great info there. I did not go through the steps this time but I was quick to save them as I'm sure they will come in handy during other development efforts. 🙂
Indeed it was the McAfee virus scanner. Once I disabled the on-access and other running McAfee services I was able to build over and over again without seeing the crash. Then turning the virus scanner back on only allowed me to build once and then the second attempt crashed the InstallShield IDE.
Also, with the virus scanner turned off, my project built a lot faster too.
I don't think the InstallShield IDE should crash so horribly if a folder is locked or some 3rd party process is doing something considered normal.
It should probably just halt the build and complain with an error; I have seen it do it this more graceful way when a Windows Explorer navigation window is open looking at the media's release folder and a more graceful halt of the build would be better.
A defect might be a good idea for the InstallShield dev team but I'll leave that up to others to decide.
Still, thank you very much MichaelU for the fix and resolution of this thread!! 🙂
And also, thank you xprt4y for the great investigation details!! That's some great info there. I did not go through the steps this time but I was quick to save them as I'm sure they will come in handy during other development efforts. 🙂