Remove BlazeWCP on the fly?
 

I'm using BlazeWCP for a while and it appeared to be a useful patch in many ways. But unfortunately it also seems to conflict with a few other processes in the background. I was just wondering if I could use this patch on demand. It is no problem to run it later from CLI or script instead of putting it in the Startup-Sequence, but how do I get rid of it? The docs don't say anything about this issue and the usual way via the Break command doesn't work because it's not listed in the process list. Any ideas?

Did you tried Scout? I think you need at least PatchControl or SaferPatches running for that.

Thanx for the hint. At least Scout is able to list all the installed patches, but since the Enable/Disable buttons are greyed out there's still no way to switch them off (or I'm not aware of it).

You have to select a function first then you can disable/enable. If that works for you, you can use Scout`s ARexx Port or use the shell command if patches are supported. If not ask the author to add that feature. :)

Maybe better to use the Task list. Find BlazeWCP in the list and then freeze/acivate/...

I think there is a tool on aminet for disable/enable patches.

BlazeWCP doesn't appear in the task list (that would be way too easy :p). In the patch list BlazeWCP has 3 entries, but the enable/disable buttons remain greyed, even when selecting one of them.
A small tool to disable patches would be useful, but I still couldn't find any (in fact I really don't know what I have to look for).

At least you need SaferPatches or Patchcontrol running. Else you can`t enable/disable patches.

Hmpf... nothing works :( This is what I did: As mentioned in the manual, I first used Scout in conjunction with SetMan to enable the patches list. Without it, the whole list is inaccessible. Now I was able to open the list, but couldn't change anything (buttons are greyed). With SetMan in the background I can't use SaferPatches or PatchControl, because both think they're already installed. I tried to use both programs on their own, but neither one of them enabled the patches list. Scout doesn't seem to recognize them, although the PatchControl manual says it's 100% compatible with SetMan. This is frustrating!

I would recommend to install TRSaferPtch.lha from Thomas Richter:
http://aminet.net/search?query=TRSaferPtch.lha

What processes is BlazeWCP messing with ? as its one of those patches you trust to be the best at what it does and not give it any thaught when trouble shooting.

@Mad-Matt: The most important thing is that it causes my system to freeze every time I insert a mixed mode CD (with data & audio tracks). These CD types will be mounted 2 times: With IDEFix' CacheCDFS to access the data part and with CDDA-FS to access the audio part (via DOS). Deactivating one of them would fix the problem, but would also be very inconvenient, because I use them both very often. And yes, BlazeWCP is one of those tools you usually trust and it took me some time to figure out that it is responsible for the hang.

@PeterK: That's a good one! Not only it activates the enable/disable function in Scout's patch list, it also brings the ability to enable/disable patches by itself. Now I need to learn more about these '.fd' files which are often mentioned in different documentations, but never explained. Without 'em the pach lists don't show any names and I had to id the patches by the corresponding library and it's offset - too hard for me! :D
Does anyone know more about that?

BlazeWCP only patches WritePixelLine8/WritePixelArray8 and WriteChunkyPixels (on V40+ systems). I don't think that it has anything to do with the crash you're experiencing when you insert mixed mode CD's. Did you try to disable other patches too?

Since BlazeWCP's source is available it shouldn't be too hard to adapt so that it'll remove itself when it's started a second time. Let me know if that would be interesting/useful for you.

Yes, well... the only thing I can say is that turning off BlazeWCP solves the problem and turning off any other patch doesn't. But you might be right, maybe it kind of 'cross conflicts' with another process (and breaks something) which finally causes the crash and thus it's not directly responsible. At this point it's getting too complicated to find the true culprit. I think it is generally a good idea to attach an off-switch to every program which is meant to remain in RAM for further functionality to avoid this trouble. So if it would be possible & not too much effort to add that option it would be VERY appreciated.

@pintcat
please, check DEVS/DosDrivers/CD0 for the "StackSize" and set it at least to 3000 bytes. Sometimes, there are still some older CD0 files hanging around with just 600 bytes stack. That's not enough and causes crashes when these devices are mounted. Some FD files for the start:

Thanx for the archive, it contains a lot of stuff. These .fd files look like they have been extracted from source codes or something. Is there any documentation on this format, especially on how to write/generate an .fd file?

Usually, these FD-files belong to the SDKs (software development kits) of the libraries. For the AmigaOS it's the NDK with the Includes and you can find it here: http://os.amigaworld.de/index.php?lang=en&page=1 or more exactly here: http://os.amigaworld.de/download.php?id=3

I'm sorry pintcat, but atm I can't find the utilities for generating FD-files or the documentation at least.

Hell, I was so glad about having found a way to deactivate this patch that I forgot the main purpose of my request. Unfortunately, disabling BlazeWCP doesn't fix anything! :crying As StingRay said, just patching the graphics.library doesn't cause the crash. Obviously, once it has been placed in RAM the OS is condemned to freeze if it tries to mount a mixed mode CD. Odd... it sounds more and more like a memory issue.

Did you already check the stacksize of Devs/DosDrivers/CD0 as suggested above?
You could also try to install 'MinStack 10000' and 'MemTrailer 96' in your startup-sequence.
Maybe one of them can help you to avoid memory trashings.

http://aminet.net/search?query=minstack
http://aminet.net/search?query=memtrailer

Put them both below SetPatch

Sorry, I already checked this, but forgot to let you know... The stack size in the CD0 mountlist is at 3000 which is the default I guess. In the CDDA mountlist, the stack size even is at 4096. Changing any of these to a higher value doesn't help. Also, I tried these 2 memory patches you suggested, but without any success. I'm afraid I have to look for another solution since I'm hopelessly out of ideas right now. Mounting one of both media types manually after booting doesn't do any trouble and it would be easy to add this as an option to the workbench menu or to some application like DiskMaster - a solution I can live with. Anyway, thanx for all your help and advices; that was quite educational!

* Gotta watch football now... :great*

Do you use any special icons (other then default) for the mounted cd data / cd audio device icons ?. iev certainly had crashes in the past where certain cd would instantly crash the amiga when inserted, but more often have the amiga crash if the cd is already in the drive while workbench is booting. Instant crash once workbench opens. got a few magazine cds that cause this effect.

Something worth investigating, try changing the default icon sys:prefs/env/cdda.info or move/delete all together and see if the issue improves.

I use default icons only. I tried what you said, but without any change. The interesting thing is that the system doesn't crash when the CD is already inserted before or during the boot up, but it will be very instable then.