This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 30%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET0%3C/text%3E%3C/svg%3E)
My release executable(==L) is 1,526 KB, runs flawlessly on both my Windows 7 desktop and 5 Window 10/11 desktop/laptop computers but not on one Window 10 desktop computer. The same happened while developing it in VS Community 2022. The first time it happened in this VS Community 2022 Windows reported that another program was waiting for L's response. I detected it was Microsoft OneDrive(==MOD) by "end tasking" it in the taskmanager making L show on the screen. So far the facts! Some want to see/test/use my executable L. But I can't guarantee L will run visibly on the sreen. So obviously my code is lacking the ability to escape from this dilemma! If I only knew HOW! Stronger still I can't understand L running OK on so many Windows 10/11 computers. Most of them like my own Windows 10 should have MOD active, I even asked it and it was confirmed! So I have to admit I don't know of any solution for this dilemma! I can imagine some Window Messages going up and down the pipeline that my MainWndProc() has to deal with to end this dilemma. CAN ANYONE HELP ME?
Hi @TonEpskamp-0986 ,
Could you please tell me how to reproduce this problem? Does the problem exist on a computer without one drive?
Dear YujianYao-MSFT,
My release version is over 1.500 KB so reproducing on a very small scale does seem impossible. But I might improve my statement because it even is happening while developing. Whenever I start a debug/release version it will quite regularly happen that my executable will not show unless I "end task" Microsoft OneDrive in the taskmanager. It happened yesterday anyhow! I detected this phenomenon by using the taskmanager! My Windows 10 is as old as my PC: 4 years. But the same will apply for many people I want to distribute my release version with. Any distribution will have to wait on some kind of a solution for this nasty problem. But I ran my release version even on a Windows 7 computer! So far I have found 1 laptop and 1 desktop generating the same issue. But I did not meet any problem on most Windows 10/11 computer systems. I will be prepaired to solve this problem even on a low level base but I lack the knowledge how to process this; no Window Messages like WM_CLOUD or WM_ONEDRIVE seem to exist! I wonder who on earth or in our Mily Way galaxy could help me? I severly hope somebody at Microsoft!
Hi @TonEpskamp-0986 ,
I am afraid it is difficult to find out the reason based on the description, I suggest you check whether there are differences in the configuration of other computers, if this problem can be stably reproduced in the future, please contact us again.
Hello,
it sounds like your programme is trying to communicate with OneDrive at startup before any mainframe window is shown. IMO this is not a good workflow - start the check for communication with OneDrive after startup, e.g. in a worker thread.
Show us the code how you try to access OneDrive at startup.
Maybe add the OneDrive-tag to your question: office-onedrive-client-itpro.html
Regards, Guido
Hi YujianYao-MSFT,
There were only two 64-bits Windows 10 computers where my release version didn't show on its screen. One a laptop and the other a desktop computer. Both owners denied the presence of Microsoft OneDrive on their systems. My code is without a signle bit concerning the cloud or Microsoft OneDrive/GoogleDrive. This morning before starting Visual Studio Community I started my debug version not showing on the screen. After a few minutes waiting I started 3 more copies of it and decided to continue doing something else with the taskmanager showing on my screen both my four debug versions and Microsoft OneDdrive as Background Processes. Suddenly in a flash my last copy showed and closing the last one showed all previous copies! Simultaneously promoting my four debug versions to Apps. Though I have 3 Windows computers I can have access to the same doesn't apply for all of those systems I tried te start my release version on. So I have to believe their owners about Microsoft OneDdrive's presence. I am not completely sure but I think starting tomorrow the same way should behave the same way also: reproducing it stably. I will tomorrow restart the exactly same way anyhow!
Hello Guido,
I am convinced you are right because the first time it happened using Visual Studio Community Windows warned me that "Another program was waiting for an answer from this by me started debug version" with my started executable NOT showing on the screen! Using the taskmanager confirmed this because "end tasking" Microsoft OneDrive showed my executable on the screen. So you are obviously right! It is however very sad this will not solve my problem of not showing my release version on some computer's screen! And that will be my nearly unsolvable task because I am a complete layman in these matters. But as far as I can see ALL Windows programs run without any problem: I never heard anyone complaining about my above mentioned error message. That should mean solving it how low or high level its solution might be it has to be done easily and quickly! IF I ONLY KNEW! Many thanks for your interest!
I think you should check the startup routine when your programme tries to communicate with OneDrive. When you kill the OneDrive process in TaskManager, the communication in your programme is interrupted and the programme goes on running to showing the mainframe window.
So there is a problem with your communication source code in your programme. If you check it, maybe you will find the root of the problem. It sounds like communication or the connection to OneDrive is hanging. You can for example try to decrease the timeout value time, too, so that the communication interrupts earlier.
Nevertheless, give more details like the source code of your startup OneDrive-communication so that we can try to help you.
Regards, Guido
Hello Guido,
I am terribly sorry that I didn't mention that I don't have a single bit of code in my program dealing with (communication with) the cloud, GoogleDrive or Microsoft OneDrive. I even don;t want the cloud for backup or any other service nor do I need the cloud. I certainly don't despise the cloud because of its importance for so many other people. Besides that I wouldn't be able to communicate with any other program by missing both knowledge and interest. So my knowledge is poor but all the same apparently Microsoft OneDrive might want to communicate with my executables! So I am a long way from understanding because my executables will start visibly on nearly every Windows 7-11 excepted one laptop and one desktop! So in all cases this communication is apparently well dealed with by my executables in spite of my lack of any communication with only 2 exceptions. Do I need to start a dalogue anyhow with GoogleDrive or Microsoft OneDrive for those 2 exceptions? I only hope preferably not! I thank you, Guido, for your interest!
Dear Guido,
You are the first reporting to me about any dialogue between Windows or Microsoft OneDrive and my executable. First of all I should admit that I really thougt that all communication always is between any program and Windows. So I have to ask you: "Is there actually communication between executables?". That is because I really do both think and hope that could finish my problem. But though using [Main]WndProc()'s over decades I don't have the faintest idea with which Window Messages we are dealing here: never too old to learn! My executable's not/delayed showing on a computer's screen might completely both disappear and be solved when I know how to deal with any attempt to communicate with my executable. If this might actually be the solution I will be left with the question: "Why only in those few two cases?"! Please help me understanding!
Since your programme doesn't communicate with OneDrive and since the behaviour is only seen on some Windows systems, I'd say that there is no problem in your code but there is a problem with your Windows system.
You should check all incoming Windows messages at startup before the mainframe window is shown. You should find out which message blocks your programme.
Check the Windows messages with Spy++ for example.
Regards, Guido
As long as your programme is not written to communicate with another exe, there will be no communication.
I don't think that OneDrive communicates with your programme because - as you say - you didn't implement communication with OneDrive.
Your programme can receive Windows messages which could possibly block the startup process. You should find out if that happens (see before).
Another possibility is if your programme needs a lot of memory space. If the Windows system cannot provide it at once, maybe it maps memory to the harddisk.
If you cannot find the cause in your source code, I suggest you to ask in a Windows forum
Regards, Guido
Do you perhaps try to access/open a file on OneDrive at startup?
Dear Guido,
Again trying to execute your recommendations I observed - as I already knew - the impossibility to debug any program in its startup phase! Aiming to do just that will need to start a debug session before your executable has gone through it already and Visual Studio(==VS) will prevent just that: VS will only start any debug session when your executable is already showing on the sreen. Just claiming a debug session without your executable showing on the screen will generate an error message about your executable not yet active. In most cases never a problem but debugging its startup phase has decades of years ago being possible and seems - for me - now impossible. I was hoping to detect in its message queue a message connected with OneDrive's interfering! Frustrated I started Spy++ from VS's toolbar - never done before - but Spy++ will ask for a window handle I only will be able to provide when my executable is already on the screen having finished its startup phase! I obviously am not the professional you are used to communicate with! I am left hoping I am making a terrible mistake I am so far not aware of! I think I have to apologize for being terrible non-professional!