After a job has been executed (the job is already finished), how will you know, if it ran via foreground or background?
Do I go to sm37 and see it there? When I select the job name and type JDBG, I still don't see it.
The foreground jobs does not have an entry in SM37. SM37 is only for the scheduled background jobs. I hope you are not confused between dialog jobs and dialog work processes.
A dialog work process has a run-time limit that prevents users from running long reports. Background work processes allocate memory differently than dialog work processes so that background work processes can become as large as they need to in allocated memory to allow for processing large volumes of data.
In SM37, you need to have the checkbox next to the job name checked and then type jdbg. When you press enter the debugger should popup.
Edit: Typo
Related
I have a humble VB.Net forms app with a listener for the Windows security log. It's configured such that whenever a network login succeeds or fails (Event ID 4624/5, Logon Type 3), it records the associated source IP and username used to log in, printing these (with the program's own timestamp) to my output log form.
It works great - until, for no reason that I can clearly ascertain, the program suddenly reads my entire Windows Security log and dumps every single "matching" event that has ever happened into the form – which promptly crashes the program (freezes it actually, but I kill it first... it takes a loooong time to finish when this happens).
Now, upon examining the output one such occurrence, the timestamps DON'T match the actual event log. They start at the time that the program "panics" and reads the entire log from beginning to end. So an event that happened two days ago has a timestamp from today in the program, because that's when the program "read" the data.
But, how in the world is this happening when the EntryWritten event should only be raised when each event is actually added? It's like every single entry in the log is suddenly a "New Entry" all over again. This seems to only occur on my Windows 10 PC, and NOT on my Windows Server 2019 machine.
Possible trigger (or at least synchronous) events have included:
Logging into a shared folder on this machine from another machine
Logging into RDP on another machine from this machine
Opening a website in Microsoft Edge
I'm totally lost here; I don't even know if this is a Stack Overflow question or a Super User question... but since cross-posting is frowned upon, I'll start here. Also worth noting, no new event is even added when this happens. It stops at exactly where the log was at when the flood started; actually new events that occur after the flood begins do not seem to get included in the flood. (I may be wrong about this, but I don't have a reliable way of checking - the above methods are not repeatable, unfortunately.)
Update: I can with 100% reliability induce the "Event Recall Flood" by repeatedly failing an RDP login from the machine in question to another machine. Not sure why this is causing every event in the Security log to fire the EntryWritten event though...
The Security event log (probably the others as well) in Windows 10 (Ver. 1909 Build 18363.778) will "reprocess" the entire log when it hits capacity and is trimmed, causing all remaining events in the log to display themselves as "new events" to any attached EventLog listeners, resulting in a flood of EventWritten triggers that will hang an application if the log is sizable. (Min. size is 20Mb as of this writing, about ~31,000 events... so yeah.)
This effect can be curtailed: (1) temporarily, by emptying the log; or (2) more permanently, by configuring the log to "Archive the log when full, do not overwrite events."
Huge thank you to Andrew Morton for the spot-on tips on where to look! As he mentioned in his comments, this "seems like a bug." It has now been reported to Microsoft Feedback Hub with documentation.
Can someone of you help me, how to make the following service selected in the image get into wait mode after starting the server.
Please let me know if developer trace is required to be posted for resolving this issue.
that particular process is a BATCH process, a process that runs scheduled background tasks (maintained by transaction SM36/SM37). If the process is busy right after starting the server, that means there were scheduled tasks with status released waiting for execution, and as soon as the server was up, it started those tasks.
If you want to make sure the system doesn't immediately start released background tasks, you'll have to set the status back to scheduled (which, thanks to a bit of weird translation, means they won't be executed because they are not released).
if you want to start the server without having a chance to first change the job status in SM37, you would either have to reset the status on database level (likely not officially supported by SAP) or first start the server without any BATCH processes (which would give you a number of great big warning messages upon login) and change the job status before then restarting the server with the BATCH processes. You can set the number of processes for each type in the profile of your instance (parameter rdisp/wp_no_btc).
I ran into a very weird problem. I have a VB.NET program which calls another program which runs in the background. We're using a special software here to deliver this software over web. What this software basically does is, that i creates a new remote desktop connection, grabs the screen and opens up a web server.
While running the sub programm / sub process the screen does not react smooth anymore, it gets very low and then freezes. We figured out, that we're triggering too many screen updates at once so that we simply flood our connection which causes the crash in the browser.
Is there any simple way to determine how many screen updates were sent and which causes these updates? Best would be that we can identify the process so that we can investigate further.
The whole process is ran as a backgroundWorker which then creates another process.
Edit:
Could it have something to do with the CPU load (which is very high)? Although the subprocess is executed in the background - and is visible in the process list - is there any chance that this causes the UI Update?
Finally solved it. It was a Timer updating the View every microsecond becuase the Interval was not correctly set.
I have a VB.NET desktop application that I'm using to monitor events in another windows application running on my system. I need to respond to certain events in a matter of seconds. One of the events I'm monitoring instantly changes the window title of a child window within the main process (I'm not changing it, the application I'm monitoring causes the change in it's own child window title). I have a function that uses windows API's to iterate through the title text of all the process's child windows, and I'm checking for certain values in the titles.
Is it a bad idea to be running this timer/title check once every second? Are there performance issues associated with running a timer in windows every second 24/7? Is it also bad for performance to be calling the API's which retrieve the titles of all the application's child windows? Could I eventually cause that application to crash by sending requests to it so often?
Thanks!
You will have to benchmark it to see, but if I recall correctly, iterating through every window has significant overhead.
Can't you simply monitor a single window? If you do that, you should be fine.
I want to write a program, that should be notified by O.S. whenever any running process on that OS dies.
I don't want to myself poll and compare everytime if a previously existing process has died. I want my program to be alerted by OS whenever a process termination happens.
How do I go about it? Some sample code would be very helpful.
PS: Looking for approaches in Java/C++.
Sounds like you want PsSetCreateProcessNotifyRoutine(). See this article to get started:
http://www.codeproject.com/KB/threads/procmon.aspx
Under Unix, you could use the sigchld signal to get notified of the death of the process. This requires, however, that the process being monitored is a child process of the monitoring process.
Under Windows, you might need to have a valid handle to the process. If you spawn the process yourself using CreateProcess, you get the handle for free, otherwise you must acquire by other means. It might then be possible to wait for the process to terminate by calling WaitForSingleObject on the handle.
Sorry, I don't have any example code for this. I am not even sure, that waiting on the process handle under Windows really awaits termination of the process (as opposed to some other "significant" condition, which causes the process handle to enter "signalled" state or something).
I don't have a code sample ready but one idea – on Linux – might be to find out the ID of the process you'd like to watch when first starting your watcher program (e.g. using $ pgrep) and then using inotify to watch /proc/<PID>/ – which gets deleted when the process dies. In contrast to polling, this doesn't cost any significant CPU resources.
Now, procfs is not completely supported by inotify, so I can't guarantee this approach would actually work but it is certainly worth looking into.