SkyGuide/SkyGuard 32 bits version supports Maxim-DL but as a consequence is limited to guider images/frames up to 1 Mpixel.
This is a direct result and legacy of Maxim-DL which is a 32 bits application, this limitation applies even when used without Maxim-DL on ASCOM only configuration.
We’ll release an ASCOM only 64 bits application shortly which will not have such limitation anymore.
If you face the 1 Mpixel limit you have 3 solutions:

-1-

Bin the guider, like 2×2 or 4×4.
Beside this is usually a good idea when guiding (at least with focal lengths > 500mm, most guider featuring small pixel size), its improves SNR without any significant reduction on the auto-guiding resolution.
Our full frame technology has a 1/10 of a pixel calculation accuracy.

-2-

You can crop the guider frame (see guider exposure setting).

-3-

You can use the Block Compression option in the advanced tab of guider.

Block compression splits the guider full frame in sub-frames of same size, for instance if you set the block compression factor at 2 (the default value being 1) you will have 4 sub-frames, and then they are added (summed) together to create one single smaller frame (1/4 of the full frame in my example).
This concatenated sub-frame is used for guiding and focusing.
Our full frame technology and related algorithms process the all guider image/frame, here the concatenated sub-frame, it does not make any assumption about the nature nor shape of the pattern inside the guider frame.
As a result the block compression allows you do decrease the size of the frame to be processed down to 1 M-pixel, without removing any information, unlike cropping may.

For instance if you have a 16 M-pixel image from your guider and you do not want to bin more than 2×2, you could then use the block compression with a factor 2 to reach the 1 M-pixel limit.
However I still suggest to bin 4×4 when doable. The software supports binning above and beyond most guider driver capabilities, if you elect to do so (say bin 6×6, as an example), it will automatically split the binning process between a hardware binning and a software binning.

Binning and/or copping leads to a higher guider image transfer rate than block compression does, since the image from the guider is physically smaller to begin with.

To take a dark frame use the last (most right) button of the button bar of the acquisition section (upper left of the GUI).
The active the simple dark in the acquisition advanced tab.

SKG is processing the all frame and does not make any assumption about what is inside it (most likely stars though). It will be able to guide as long as there is something else than noise. In short SKG is based to a global image processing.

SKG uses advanced statistical techniques and per-processing of the guider image to extract the relevant information from the noise floor.

In this global approach context hot pixel can been some time confused with “tiny” stars and if there are a lot of them SKG may come to the conclusion there is no motion detected between guider frames since hot pixels do no move.

Therefore we recommend to use the dark frame subtraction when doable and set the median filter to 2, the default value, even if you use a dark frame.
In the unlikely case where you face tiny stars removal due to the median filter you could defocus just a bit the guider to spread the starlight across more pixel, this should be seldom necessary.
The hot pixel are not affected by this operation and therefore will be removed by the median filter while tiny stars will be preserved.
Also if you bin the guider in such conditions you may set the binning factor one notch below such the star profiles spread across more pixels.

SKG will warn about possible hot pixel (as discussed above) should you disable the median filter and do not use any dark frame.

A classical symptom of hot pixel issue with SKG (or any other auto-guiding software) would be a failure to calibrate (no motion detected, less than 5 pixel error message) despite the fact the mount has moved indeed.
The median filter and dark frame fix this.
To monitor what is going on you can look at the guider input image (processed image) on the left view-port and the reference image (select the relevant tabs) to see what SKG is using to do its calculation and if there is any motion.

If you use any ASCOM driver with SKG you should have the ASCOM platfrom 6.4 or higher installed.
Be sure that there is no older ASCOM platform version still installed, that may happen some time when installing a new one the old one may not uninstall properly.
Also I would suggest to update all the ASCOM drivers.
Since the ASCOM platfrom release 6.4 some old drivers may exhibit issue or incompatibilities.
For instance SX users (Lodestar, Ultrastar) should install the latest ASCOM driver for SX camera, it can be downloaded from here:

http://www.daddog.com/ascom/sxcamera

You should also update the SX native driver since the ASCOM driver uses the native one, which could be found here:

https://www.sxccd.com/drivers-downloads

Some Lodestar and Ultrastar cameras may exhibit quite many hot pixels, for those cameras it is usefull to enable the dark frame subtraction, when doable, however some of those hot pixel amplitudes may still change over time
(over few minutes while the guider electronics warms up) making the dark frame subtraction not fully effective for removing all hot pixels.
In consequence we recommend, as dicussed above, to also use the median filter, set at 2 (the default value).
Be sure to disable the SX ASCOM driver Gaussian blur option (under driver settings), if set.

In general if you have a fast camera with USB 3 connection capability it is a good practice to use a USB 3 cable even if your PC does not have USB 3 slot (unlike those days)
Using a long USB 3 cable is not recommended, if necessary one should consider an active cable with a repeater rather than a passive one.

For ZWO’s camera users, the ZWO ASCOM driver features a USB traffic adjustment setting from 40% to 100% (open the ZWO ASCOM driver setting tab to access it).
If you face some unexpected USB issues with the guider or if SKG starts to freeze (slow GUI) you may want to lower this value toward 40%.
Some time the ZWO ASCOM driver may report an out of memory error (which SKG will log).
It is unclear why but this is most of the time related to the USB traffic, using 40% should fix it. This is a known issue with their current driver (not specifically related to SKG).
In most systems and PCs one should be able to use 100%, or at last 60% (if you have the latest drivers). USB hubs are also not recommended with fast USB 3 links.

Also if you share ASCOM devices between applications, like the imager, FW, …, you may have to use the OPTEC ASCOM server (https://www.optecinc.com/astronomy/downloads/ascom_server.htm) if the associated ASCOM driver does offer any HUB capability.

When you start with SGK I would suggest to use an easy target first, like one of few stars (do not clip the sensor).
This is convenient to learn the software and to calibrate since you can see on the guider output view port clearly what is going on (like with a guide star), but it is not required.
When comfortable if SKG you can guide pretty much with any image even if you do not see any stars in the view port.
I would suggest to set the aggressiveness values at 30% to start with and use 5 seconds or more of guider exposure time, if doable.

When using SKG with Maxim-DL be sure that both applications run at the same level, if you run one as administrator the other must be run as administrator too.

Again thank you for using our software, feel free to contact us at any time.
Comments, feedback and suggestion are very welcome.