It's just plain bad practice to stop your code dead like that with an end statement... The end statement is there to tell the compiler there's no more code to compile, NOT to tell the processor to stop!

If you want to end execution, send the device into an endless loop...

deadloop:
pause 1000
goto deadloop ' loop till doomsday

If you examine what's happening in your PIC, the program counter keeps incrementing and your PIC will keep on executing whatever code is remenant in the PIC. When you program a PIC, unless you specify otherwise, your PIC will not first be erased, all that happens is your new code replaces what was there previously. If your new code is smaller than what was previously in memory, then some of the previous content will remain and once your code executes, it will happilly continue into whatever garbage was there previously. You must therefore terminate your program logically. Most if not all programs are continuous loops. If your application demands a 'once-only' execution, you must program-in a suitable termination. Even if your PIC has first been erased, the PIC will continue with NOP statements untill it reaches the end of program codespace at which point what it will do will be unpredictable... it might restart, it might not, but it sure as hell will be unstable.

Oh... and the reason I put a PAUSE statement in is that PICBasic will insert code to keep the watchdog timer happy. If you just had...

deadloop:
goto deadloop

then the Watchdog (if enabled) will time out and restart the PIC as PICBasic would not had inserted a CLRWDT in that instance.

...or of course use PICBasics STOP statement!

you example expanded...
.. ..
PAUSE 5000 'turn on sound for 5 seconds
PORTB.1 = 0
PORTB.4 = 0 ' TURN OFF POWER
STOP
end