Cubase Pro 12 Disables Screen Saver

Agreed. It probably explains why I find this particular Cubase behavior “lazy” and where (apparently) everybody else accepts it as “just the way it is”. Perspective.

Perhaps to you. Clearly, not to me. Otherwise, neither of us would be here.

I think I stated as much, which is why I created this bug report.
Cheers from Alaska, btw. I especially liked Ghent when I visited your country.

Again, you have zero idea what my needs are, how I utilize my systems, or why I have it set up as I do. Lots of assumptions. in your responses here.

OK, maybe sarcasm isn’t the best word. How about snark. My question to you is *why did you feel the need to stop here and make any comment at all?". I think my frustration with Cubase is clear enough, which is why I logged this issue in the first place. I wasn’t asking for help, but you still chose to comment on all the ways you believe I am wrong. Was that necessary? Or even appropriate?

At least you’d have a choice. That’s all I’m asking for, not to take anything away from you or any other user, or make your lives miserable. But here you are admonishing me for wanting that choice that you don’t even want.

That’s fine, if that works for you. But what makes you think that solution is acceptable to me, or anyone else? Again, why are you trying to tell me how I should do things just because you don’t like me suggesting that I have the option to do it differently?

Every community has its share of unhelpful “drive by” people. +1

I shall try to be less presumptive, sarcastic and unhelpful in future.

Thanks for taking the time writing and explaining all of this.
And Ghent is indeed the most beautiful city of the world (I am born there and still live there. Quite a co-incidence …)

1 Like

No it isn’t.

You need to save energy? Turn your computer off.
Screensavers and power safe modes make most audio hardware instable, and this is crashing the software sometimes.
Nearly all audio and video software disables the power safe modes and the screen safer.

So why do you write it to the community?

And what is your rant based upon? Assumptions.

Sure it is! Says it right there in the title, and it’s tagged as an issue. See? Bug Report.

:yawning_face: Not helpful.

:yawning_face: Again, not really that helpful, but :point_down: :point_down: :point_down:

:yawning_face: Snarky and not helpful. (2 points for that)

That’s a totally ridiculous statement.

:yawning_face: Also, not helpful.

I work as CISO and from an information security perspective this is definitely a problem.

If in our company Cubase would be installed on a computer that holds information that is classified as top assets, it would immediately pop up as a high risk at the risk assessment, resulting in a ban on that computer. If there is a strong requirement to have a DAW on that computer, it will be replaced by another software product. Risk management and mitigation is highly customer dependent. There are other measures like separating the information, implement physical measures, additional technical counter measures or having regular awareness trainings in place that people learn to lock their computers as soon as they are afk.

Top assets are information that have high ratings regarding confidentiality, integrity, availability and cost of replacement. I guess in most music studios the tracks/recordings from clients are considered as top assets and demand an appropriate protection. As long as most music studios work on best-effort regarding information security, I guess Steinberg can remain on the current implementation. However, nowadays the aspiration on information security management in a structured way will increase and Steinberg needs to comply.

I noticed this behavior at home as well but ignored it so far, as I have physical measures in place as well (doors…) and conditioned myself to always lock computers. The only damage I would have, if my music would e.g. leak into the internet, is maybe embarrassment that people hear my unfinished music…

The availability of computer systems is also an important aspect of information security and here license management systems are a major concern. Perpetual local licenses, dongles, cloud licensing, etc. Another can of worms and heavily discussed in this forum already.

But to summarize. Steinberg needs to cope with the raising demand on information security in a transparent way, so that it is clear, that the lock screen will be disabled when Cubase is open.

1 Like

I’m going to post another unhelpful post , we all should know that Daw’s require the least interrupts as possible to work efficiently and with the Daw in an open state all other programs behaviours should be on hold due to the priority of audio , this is by design , as others have told you ,this is not a bug or an issue , this is the way it is with Cubase .
Why don’t you retitle your topic as feature request or do you like the click bait and all the unhelpful remarks about your requirement ? It is not an issue , it is by design . The issue is your work flow falls outside the standard workings of Cubase so why not ask for the feature to help with your work flow .

1 Like

Lock screen doesn’t get disabled. Try it yourself.
Windows+L still works, and you can set your safety settings with group policies.

To say something makes it not true.
If there is no bug, it’s not a bug report and user error is not a bug, btw.

If you set the right things, it is possible to enable screen savers and automatic lock screen with Cubase.
It’s not recommended, but still possible.
So where is your bug again?

You don’t really understand how an event-driven operating system works, do you? That’s pretty much all of them. Sure, you can request that the OS raise the priority of a program manually, but that’s really all it is: a request. The only reasons DAWs work effectively today with all of their capabilities is because of the speed of the processors, proven by the fact that when you try to run one on an old computer, performance suffers, dropouts occur, users get frustrated, etc.

Plus, if you really cared to understand the issue here, you’d know that this behavior occurs also when Cubase in minimized, and in fact, even if a project is never opened. There is absolutely no reason for this, and no other DAW I’ve ever used behaves this way. Here’s an example. I just set my monitors to turn off, and my computer to auto-lock, after 1 minute. I opened Cubase (no project, just Cubase) and waited several minutes. Nothing.I closed Cubase and waited. One minute later, my monitors went into power-save mode and my computer was locked. Oh, and all the while I’ve had a Reaper project open with a TON of plug-ins active on many tracks. It didn’t seem to mind at all, and I have absolutely NO performance issues. You’re argument is as wrong as it is weak in defending this behavior. If it is indeed “by design” as you say, then it is a design flaw by any reasonable SW Engineering/Security standards. And your argument is made even more absurd by the fact that Cubase actually provides an option to the user to Release Driver when Application is in Background for the audio system.

I’m sorry, but I don’t consider it a feature for a program to, without asking or informing, change the security profile of my workstation. Neither would any of the Fortune 100 companies for which the division I previously ran managed IT infrastructure. Cubase wouldn’t be allowed anywhere near their systems. I’m a little surprised big name producers appear to ignore this issue, as data theft could be very costly and damaging to a reputation. Hopefully they have the best physical security in place and trustworthy employees.

Wrong, in the context of this discussion.But you already knew that (or would have if you had actually read the thread).

To which settings. are you referring, exactly?

Yet here you are telling me something I’ve said is not true… by saying it. :face_with_raised_eyebrow:

Then please show us how, step by step. I’d be interested to know what I’ve missed. I’ll even mark your helpful comment as the SOLUTION. I eagerly await.

You obviously have a chip on your shoulder for Steinbergs handling of a 35 year old profitable DAW so i suggest using something else . Im out of your click bait

1 Like

Running Cubase 12 on a 1st gen i7-950 X58 (Windows 10) with a firewire interface. Performance is starting to suffer (but, I have my “workarounds”). Dropouts never occur. I don’t get frustrated.

I probably don’t run my DAW with all of it’s “capabilities”, though! :grinning:

I assume the workstations you deal with are configured to automatically lock after some time of inactivity. So was the case for us (I worked in the military) However someone found out rather soon. that playing an .mp3 (loop and muted with the player in a mininized state) prevented the computer from locking …
And IT security was taken serious …

oh, that’s bad… and yes the the biggest weak point will always be people. I don’t understand what people gain when they bypass the automated lock with intent.


I have been on PC DAW platforms and using NUENDO since V1 of the program. I personally like and have ALWAYS appreciated the fact that Steinberg chose to negate the screen saver upon initial bootup of the program As a fulltime professional user of the program I just don’t want my DAW systems or monitors, for that reason, to power down at anytime when I am using the program especially during long recording periods where you may not have any interaction with the mouse or keyboard for some time like live concert recordings, etc.

If you want the screen saver to become active again then the simplest way to achieve this is to once you have booted into the program, either Cubase or NUENDO, in the upper right corner click the Minimize (-) dash icon and minimize the program window and then immediately re-open it by clicking on the Steinberg Icon in the Task Tray where it minimized to. "Don’t Re-launch the program but only minimize for a second and then Restore/Down bringing it back to full operational screen size. This takes all of less than a second of your time and Overrides the Screen Saver Lock Out on initial bootup.

Hope this helps alleviate a little frustration on your part.

Hi, @complexone, thank you for your response. I am running Cubase Pro 12 (v 12.0.52 Build 393) on Windows 10 x64 (v 22H2 Build 19045.2604) on an HP Z820 and unfortunately, the solution you suggested does not work for me. As instructed, I opened Cubase, immediately minimized it, maximized it again after 1-2 seconds by clicking the Cubase button on the Task Bar, and neither the screen saver nor screen lock activated. I had just prior set my screen saver to timeout after 1 minute (which works only when Cubase is not running). I’m not sure what might be different in our setups that allows this to work for you but not for me.

At any rate, I appreciate the suggestion. Cheers.


Sorry that didn’t work for you. It has worked for me since V1 of NUENDO and Cubase up through V12 of each program. I actually found out about it by accident when one of my other engineers had minimized the session and then re-opened it only to find that if there was no interaction for a period of time that the screen saver actually kicked in automatically. It has also worked on every other clients DAW running those same programs so I don’t understand why this does not work for you. Let me look into this further for you and if I can find out anything further I will be back in contact with you.

I’m actually setting up another clients DAW today and once I have N12 installed I will test it on his system as well and let you know what I find out.

Complex One Digital Post

Did not work here either.

I am curious to precisely understand how you got this to work, as it’s not supposed to according to the specification, and I cannot make it work here. Are you sure there’s not some missing step or maybe an app that disables the Cubase policy?

Hi @complexone, thanks. I am indeed very interested in figuring out how I can make this work on my system if you are able to find the difference. Note that I do not have Nuendo on my system, so not sure if that could be a factor. If you have a system with just Cubase on in, that might be a good one to check to eliminate any potential Nuendo influence. I appreciate your help.

I’m totally guessing here, but a common way Windows allows programs to hijack the screensaver is by changing the application Thread state through its API. This is preferred to actually changing the users Screen Saver/ Screen Lock setting itself (which causes all kinds of other issues). This preferred solution is tied to the application only, and dies with it (in the event of a crash). It would use code such as the following when Cubase launches:

public static void HijackScreensaver()

which sets the program thread to a state that keeps the screen saver from activating. If this is indeed what Steinberg is doing, then a SIMPLE and more user friendly replacement would be something as simple as the following modification:

public static void HijackScreensaver()
    if ( UserWantsScreensaverDisabled ) {

where the Variable UserWantsScreensaverDisabled would be an additional option in the User Preferences dialog that provides every user the ability to choose for themselves whether to have this behavior or not. IMO, there is zero need to enforce this behavior on everyone, or else every DAW would be doing it.

If Cubase uses the approach above to hijack the user’s security settings, then as far as I know, there is no way for another app to undo that Thread elevation. Whereas, if they actually changed the user options set in Control Panel, one could potentially have a script to set it back while Cubase is running. That doesn’t appear to be what they are doing.